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 for
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
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
>
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 table
"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 rep
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 othe
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 t
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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 just to
extract the data
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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 someone would pull
CSV data
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
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.
>
> We
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*
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 fe
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
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 o
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
of which have also been discussed for
pg_dump recently.
- Bill
>
> > > -Original Message-
> > > From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, June 12, 2006 4:15 PM
> > > To: Bill Bartlett
> > > Cc: 'Andrew Dunst
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 cust
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 slightest
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 any
baz" "bing"
Sincerely,
Joshua D. Drake
-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 opt
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
---
> > 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
> >
>
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 this
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 syntax
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
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
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 --csv=opt0
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
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 PR
"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 imp
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
> >> wh
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
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 fil
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 shoul
the ability
to export 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'
> Subje
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. ===
Sales/S
Monday, June 12, 2006 2:16 PM
> 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 l
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
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,
No it won't, not if there are tabs in the data.
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. ===
Sales/Suppor
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
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 stu
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 o
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 mi
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 ind
48 matches
Mail list logo
