Tom Lane said:
Andrew Dunstan [EMAIL PROTECTED] writes:
This is just nonsense. There is not the slightest reason that CSV data
cannot be embedded in a text dump nor exist as the data members of a
custom or tar dump with the corresponding COPY statements modified
accordingly.
Well, the
I agree with Andrew. If there are bugs in CSV, then we should fix them,
not avoid give users this usability improvement. I know I have analyzed
the code and fixed a few problems with it in the past.
As far as pg_dump, I am thinking the most flexible solution would be to
allow an arbitrary WITH
Bruce Momjian pgman@candle.pha.pa.us writes:
I agree with Andrew. If there are bugs in CSV, then we should fix them,
not avoid give users this usability improvement.
The case for it being a usability improvement seems very weak to me;
no one has yet demonstrated an actual use-case where
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I agree with Andrew. If there are bugs in CSV, then we should fix them,
not avoid give users this usability improvement.
The case for it being a usability improvement seems very weak to me;
no one has yet demonstrated an actual
Bruce Momjian pgman@candle.pha.pa.us writes:
As was stated before, the use-case for this is by people we don't
normally have contact with.
Or who don't exist.
Once again: give me a plausible use-case for pulling this data out of a
pg_dump output file. You'd need data-massaging code anyway
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
As was stated before, the use-case for this is by people we don't
normally have contact with.
Or who don't exist.
Once again: give me a plausible use-case for pulling this data out of a
pg_dump output file. You'd need
On Tue, Jun 13, 2006 at 09:14:48AM -0700, Joshua D. Drake wrote:
I don't get it. If you can use psql then you already have csv support.
psql -c 'COPY pg_class TO STDOUT WITH CSV' postgres pg_class.csv
If you data looks like this:
foo barbaz bing
You are o.k. You have three
On Wed, Jun 14, 2006 at 10:55:04AM -0400, Bruce Momjian wrote:
Once again: give me a plausible use-case for pulling this data out of a
pg_dump output file. You'd need data-massaging code anyway just to
extract the data, so why not expect that code to convert to CSV or
whatever other
Andrew Dunstan [EMAIL PROTECTED] writes:
The CSV definition and its lack of formality is a complete red herring in
this, as are references to Microsoft.
I think then you've missed the real issue.
The real issue in what you say here is your suggestion that we might not be
able to reproduce
Bruce Momjian wrote:
As was stated before, the use-case for this is by people we don't
normally have contact with.
I do think we need a use case for what we do.
The main use case seems to me to be where you are exporting a whole
database or most of it with a very large number of
Andrew Dunstan wrote:
Bruce Momjian wrote:
As was stated before, the use-case for this is by people we don't
normally have contact with.
I do think we need a use case for what we do.
The main use case seems to me to be where you are exporting a whole
database or most of
Greg Stark wrote:
And before you ask, yes, virtually every version of Excel has changed its csv
file format.
I'd be interested to hear of Excel variants we haven't catered for - our
CSV parsing is some of the most flexible and complete around, IMNSHO.
BTW, I suspect we won't see too
I wrote:
The main use case seems to me to be where you are exporting a whole
database or most of it with a very large number of tables, and it is
convenient to have all the CSVs created for you rather than have to
make them manually one at a time. You could get these out of, say, a
tar
Bill Bartlett wrote:
Can't -- the main production database is over at a CoLo site with access
only available via SSH, and tightly-restricted SSH at that. Generally
one of the developers will SSH over to the server, pull out whatever
data is needed into a text file via psql or pg_dump, scp the
Matthew T. OConnor said:
Bill Bartlett wrote:
Can't -- the main production database is over at a CoLo site with
access only available via SSH, and tightly-restricted SSH at that.
Generally one of the developers will SSH over to the server, pull out
whatever data is needed into a text file via
Andrew Dunstan wrote:
Matthew T. OConnor said:
Bill Bartlett wrote:
Can't -- the main production database is over at a CoLo site with
access only available via SSH, and tightly-restricted SSH at that.
Generally one of the developers will SSH over to the server, pull out
whatever data is
Andrew Dunstan [EMAIL PROTECTED] writes:
I wish I could understand why people are so keen to make other people turn
handsprings in order to avoid a feature which, as Bruce points out, is
already on the TODO list, and which, by my 10 minute analysis, would involve
almost trivial code impact and
Good point. The number of CSV options would be hard to support for
pg_dump. Any thoughts from anyone on how to do that cleanly? Could we
just support the default behavior?
---
Tom Lane wrote:
Andrew Dunstan [EMAIL
On Tue, Jun 13, 2006 at 10:20:53AM -0400, Bruce Momjian wrote:
Good point. The number of CSV options would be hard to support for
pg_dump. Any thoughts from anyone on how to do that cleanly? Could we
just support the default behavior?
What this tells me is that we need a tool somewhere
On Jun 13 10:20, Bruce Momjian wrote:
Good point. The number of CSV options would be hard to support for
pg_dump. Any thoughts from anyone on how to do that cleanly? Could we
just support the default behavior?
IMHO, it might be better if we'd support a syntax like
pg_dump
Tom Lane wrote:
there are half a dozen more sub-options, and it seems like every time we
turn around someone is finding a reason for another one.
This is a bit unfair. The feature was introduced in 8.0, and slightly
enhanced in 8.1. There have not been any additional CSV features this
Bruce Momjian wrote:
Good point. The number of CSV options would be hard to support for
pg_dump. Any thoughts from anyone on how to do that cleanly? Could we
just support the default behavior?
Although I don't see a real need for the feature, I do think that if we
were to support 1 (well
Volkan YAZICI wrote:
On Jun 13 10:20, Bruce Momjian wrote:
Good point. The number of CSV options would be hard to support for
pg_dump. Any thoughts from anyone on how to do that cleanly? Could we
just support the default behavior?
IMHO, it might be better if we'd support a
Martijn van Oosterhout wrote:
Side note: In my experience Excel happily slurps up tab delimited
output, so I'm not sure why all of this is an issue in the first place.
I guess you experience doesn't run to data that has embedded tabs, for
example.
There really is a reason we did
]
Sent: Monday, June 12, 2006 4:15 PM
To: Bill Bartlett
Cc: 'Andrew Dunstan'; 'Tom Lane'; 'PG Hackers'
Subject: Re: [HACKERS] CSV mode option for pg_dump
Bill Bartlett wrote:
Here's me speaking up -- I'd definitely use it! As a
quick way to pull
data into Excel to do basic
On Jun 13, 2006, at 7:34 AM, Martijn van Oosterhout wrote:
What this tells me is that we need a tool somewhere between psql and
pg_dump, say, pgquery. It's sole purpose in life is to generate output
from various queries. Because it's a seperate tool there's no question
of psql or pg_dump being
Message-
From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
Sent: Monday, June 12, 2006 4:15 PM
To: Bill Bartlett
Cc: 'Andrew Dunstan'; 'Tom Lane'; 'PG Hackers'
Subject: Re: [HACKERS] CSV mode option for pg_dump
Bill Bartlett wrote:
Here's me speaking up -- I'd definitely use it! As a
quick way
From what I gather, the CSV format dump would only contain data.
I think pg_dump is the friend of pg_restore. It dumps everything
including user defined functions, types, schemas etc. CSV does not fit
with this.
Besides, people will probably want to dump into CSV the result of
PFC wrote:
From what I gather, the CSV format dump would only contain data.
I think pg_dump is the friend of pg_restore. It dumps everything
including user defined functions, types, schemas etc. CSV does not
fit with this.
This is just nonsense. There is not the
Would that be adequate, or do we really want to reimplement and maintain
all
the output format complexity in our own code, in C?
I think the point is that we should provide a native implementation
because not everyone is crazy enough to use perl (blatant jab ;)). I
would never expect a
PROTECTED]
Sent: Monday, June 12, 2006 4:15 PM
To: Bill Bartlett
Cc: 'Andrew Dunstan'; 'Tom Lane'; 'PG Hackers'
Subject: Re: [HACKERS] CSV mode option for pg_dump
Bill Bartlett wrote:
Here's me speaking up -- I'd definitely use it! As a
quick way to pull
data
On Jun 13, 2006, at 9:47 AM, Joshua D. Drake wrote:
Would that be adequate, or do we really want to reimplement and
maintain all
the output format complexity in our own code, in C?
I think the point is that we should provide a native implementation
because not everyone is crazy enough to
Steve Atkins wrote:
Would that be adequate, or do we really want to reimplement and
maintain all
the output format complexity in our own code, in C?
Code to produce CSVs is there, now, today, and has been since 8.0. That
is *not* what is at issue here. If you want to debate whether
pg_dump CSV TODO item removed until we come up with something everyone
can agree on.
---
Joshua D. Drake wrote:
Would that be adequate, or do we really want to reimplement and maintain
all
the output format
Bruce Momjian wrote:
pg_dump CSV TODO item removed until we come up with something everyone
can agree on.
That's a pity.
Just to show you how little is involved in what I was suggesting, a
prototype patch is attached - it's 182 lines of context diff, which is
pretty small for a new
Andrew Dunstan [EMAIL PROTECTED] writes:
This is just nonsense. There is not the slightest reason that CSV data
cannot be embedded in a text dump nor exist as the data members of a
custom or tar dump with the corresponding COPY statements modified
accordingly.
Well, the really *core*
Something someone said on IRC just now triggered a little memory ... I
think we should provide an option to have pg_dump work in CSV mode
rather than text mode. This probably doesn't have much importance in the
case of text dumps, but in custom or tar dumps where you might want to
get at
Andrew Dunstan wrote:
Something someone said on IRC just now triggered a little memory ... I
think we should provide an option to have pg_dump work in CSV mode
rather than text mode. This probably doesn't have much importance in the
case of text dumps, but in custom or tar dumps where you
Joshua D. Drake wrote:
Andrew Dunstan wrote:
Something someone said on IRC just now triggered a little memory ...
I think we should provide an option to have pg_dump work in CSV mode
rather than text mode. This probably doesn't have much importance in
the case of text dumps, but in custom
Josh,
This should be a pretty low cost item, I expect (good newbie project?)
Uhh... just about any application that can import CSV can import our
dumps. It just tell it the delimiter is a tab.
Actually, there was an Summer of Code applcation to do this, but with all
the other nifty stuff
Andrew Dunstan [EMAIL PROTECTED] writes:
Something someone said on IRC just now triggered a little memory ... I
think we should provide an option to have pg_dump work in CSV mode
rather than text mode. This probably doesn't have much importance in the
case of text dumps, but in custom or
No it won't, not if there are tabs in the data.
snipping noise
Hmmm then would just double quoting the data work? At least in OOCalc
(and IIRC Excel) there is the ability to select a text delimiter.
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Something someone said on IRC just now triggered a little memory ... I
think we should provide an option to have pg_dump work in CSV mode
rather than text mode. This probably doesn't have much importance in the
case of text dumps,
On Mon, Jun 12, 2006 at 02:15:59PM -0400, Andrew Dunstan wrote:
Naturally you won't have a use for it, but I suspect others might (in
which case they had better speak up ;-) )
I'd bet that those who would find this useful are far more likely to be
on -general and not in here.
--
Jim C. Nasby,
To: Tom Lane
Cc: PG Hackers
Subject: Re: [HACKERS] CSV mode option for pg_dump
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Something someone said on IRC just now triggered a little
memory ...
I
think we should provide an option to have pg_dump work in CSV mode
Bill Bartlett wrote:
Here's me speaking up -- I'd definitely use it! As a quick way to pull
data into Excel to do basic reports or analysis, a CSV format would be
great.
Why not just use ODBC?
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
to CSV would be handy.
- Bill
-Original Message-
From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
Sent: Monday, June 12, 2006 4:15 PM
To: Bill Bartlett
Cc: 'Andrew Dunstan'; 'Tom Lane'; 'PG Hackers'
Subject: Re: [HACKERS] CSV mode option for pg_dump
Bill Bartlett wrote:
Here's me
Already on TODO:
pg_dump:
o %Add CSV output format
---
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Something someone said on IRC just now triggered a little memory ... I
think we should
48 matches
Mail list logo
