On Fri, Jan 27, 2006 at 01:12:35PM -0500, Greg Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
David I don't get this... what are you copying from/to that would
wouldn't just script? If you throw into a script you can change
the delimiter on the fly using translation.
The
David Fetter [EMAIL PROTECTED] writes:
On Thu, Jan 26, 2006 at 10:17:05PM -0500, Tom Lane wrote:
Seems to me that psql -c 'COPY ...' is a more likely front-end for
such a process.
Actually, it's not. I'm attaching my preliminary patch, as I see I
haven't explained it well enough.
The patch
Those who don't use it will never see it.
It does however add more maintenance to the code.
Furthermore, it's quite unclear why you'd use pg_dump at all to
generate a data file that you intend to feed to some other program.
In my case, it's about being copy/paste friendly.
Joshua D. Drake [EMAIL PROTECTED] writes:
David I don't get this... what are you copying from/to that would
wouldn't just script? If you throw into a script you can change
the delimiter on the fly using translation.
I think what he's getting at is for things like, say, a contrib package with
On Fri, 2006-01-27 at 13:12 -0500, Greg Stark wrote:
Personally I find anything that would encourage people to use anything other
than tabs evil anyways. All those people who think | is somehow a reasonable
choice or want to use commas and then get all confused trying to escape them
and
Andrew Dunstan [EMAIL PROTECTED] writes:
I could not disagree more. The invisibility of tabs makes their use as a
delimiter wholly evil. I have lost count of the number of corrupted
makefiles etc. I have seen because a tab got converted to a space and it
was impossible to tell.
More tears
On Fri, 2006-01-27 at 13:43 -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I could not disagree more. The invisibility of tabs makes their use as a
delimiter wholly evil. I have lost count of the number of corrupted
makefiles etc. I have seen because a tab got converted to
Andrew Dunstan [EMAIL PROTECTED] writes:
On Fri, 2006-01-27 at 13:43 -0500, Tom Lane wrote:
That line of argument leads to the suggestion that pg_dump should just
use something else (I'd vote for |), all the time, in order to produce
more robust dump files. I still don't see the argument for
Tom Lane [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
On Fri, 2006-01-27 at 13:43 -0500, Tom Lane wrote:
That line of argument leads to the suggestion that pg_dump should just
use something else (I'd vote for |), all the time, in order to produce
more robust dump
On Fri, 2006-01-27 at 14:08 -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
On Fri, 2006-01-27 at 13:43 -0500, Tom Lane wrote:
That line of argument leads to the suggestion that pg_dump should just
use something else (I'd vote for |), all the time, in order to produce
more
Folks,
This came up at work...
I have seed database scripts quasi-generated from pg_dump which
include COPY statements, but the data is hard to edit (especially cut
paste operations) when the COPY delimiter is some non-visible
character like \t. So I thought it would be handy to be able to
David Fetter [EMAIL PROTECTED] writes:
I have seed database scripts quasi-generated from pg_dump which
include COPY statements, but the data is hard to edit (especially cut
paste operations) when the COPY delimiter is some non-visible
character like \t.
This seems like an awfully weak
On Thu, Jan 26, 2006 at 10:17:05PM -0500, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I have seed database scripts quasi-generated from pg_dump which
include COPY statements, but the data is hard to edit (especially
cut paste operations) when the COPY delimiter is some
13 matches
Mail list logo
