Very Computer

This strikes me as solving an entirely different issue -- with great
loss of backwards compatibility.  Possibly these are good ideas, but for
the moment I'd like to keep this thread focused on the issue of coping
with newline translations.

(In any case, I thought someone was already working on an optional
column-name-list clause for COPY, which would solve that problem in what
seems a cleaner fashion.)

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Well, a related issue: you are talking about (slightly) changing the
encoding of dumped data - why not therefor allow for an (optional) header
with full encoding details. Column headers are just a minor bonus.

Quote:>- with great
>loss of backwards compatibility.

Not if anything without the 'WITH HEADERS' is treated as per current.
Anyone having M$ problems can use the new format (and pg_dump could use it
always).

Quote:>the moment I'd like to keep this thread focused on the issue of coping
>with newline translations.

No big deal, but this seems to be an encoding issue; and it seems like a
good idea to formalize it somehow.

----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \

Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly

Quote:>To take just one problem: how do I know that
>the first line is metadata, and not data that happens to look exactly
>like whatever my metadata layout is?

You don't, which is why you need the 'WITH HEADER' or 'WITH ENCODING'
clause on COPY. I guess COPY could issue a warning when you do not say WITH
HEADER and it looks like a valid header.

Other than that, it's a case of storing information about the dumped data,
not the database schema in the data file. I'm not particularly attached to
the column names being there, but it does seem usefull to store
instructions indicating the the file is formatted.

----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \

Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

---------------------------(end of broadcast)---------------------------

Well, currently there is a strict separation between COPY data (in the
file) and metadata (supplied as parameters to the COPY command).  I'm
not eager to revisit that decision.  What you seem to be suggesting is
shoving metadata into the data file, but I think that will create more
problems than it solves.  To take just one problem: how do I know that
the first line is metadata, and not data that happens to look exactly
like whatever my metadata layout is?

                        regards, tom lane

---------------------------(end of broadcast)---------------------------

[2002-02-11 11:11] Tom Lane said:

| > Can you do something akin to what you did with the binary output - but in
| > this case allow for no details.
|
| This strikes me as solving an entirely different issue -- with great
| loss of backwards compatibility.  Possibly these are good ideas, but for
| the moment I'd like to keep this thread focused on the issue of coping
| with newline translations.
|
| (In any case, I thought someone was already working on an optional
| column-name-list clause for COPY, which would solve that problem in what
| seems a cleaner fashion.)

Yes, the work for a column list in COPY FROM is largely done.  I've
not been able to work on COPY TO, tho.

Part #1 of your original proposal is certainly the right thing to do.

I've backgrounded this problem for most of the day, and although I
know it's a severe change, your "stronger" solution seems like a
better change than the part #2, which just feels like something
that would only be undone later.  Both #2 and the "stronger" way
will require a SET option for absolute correctness; why not require
that SETting more often than not for any old-format dumps?  Yes, it
will affect a larger number of users, but we net a better dump
format for that pain.

cheers.
  brent

--
"Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing."  -- Duane Allman

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly