Karel Zak <[EMAIL PROTECTED]> writes:
> On Fri, Mar 19, 2004 at 09:54:37AM -0500, Tom Lane wrote:
>> Why? The client-side code doesn't have any real say over the meaning of
>> the data, at least not in psql-class clients. I suppose a client app
>> that tries to interpret the data could get confus
On Fri, Mar 19, 2004 at 09:54:37AM -0500, Tom Lane wrote:
> Karel Zak <[EMAIL PROTECTED]> writes:
> > The problem with CSV is that it will correctly work with new protocol
> > only. Because old versions of clients are newline sensitive.
>
> Why? The client-side code doesn't have any real s
Andrew Dunstan wrote:
> Josh Berkus wrote:
>
> >
> >Overall, I assert again that approaching this issue through COPY enhancements
> >is really not the way to go.We should be looking at a client utility,
> >like pg_import and pg_export. The primary purpose of COPY is bulk loads
> >for ba
Josh Berkus wrote:
Overall, I assert again that approaching this issue through COPY enhancements
is really not the way to go.We should be looking at a client utility,
like pg_import and pg_export. The primary purpose of COPY is bulk loads
for backup/restore, and I'm against doing a lot
Bruce Momjian wrote:
OK, so for the separator, quote, and escape options:
separator is ,
quote is "
escape is "
so if the quote and escape are the same, then a double denotes a
single?
Yes. i.e. with the above settings "abc""def" -> abc"def
cheers
andrew
Thomas, Andrew, Karel,
Thomas is correct: many applications which read or make CSVs will accept a
newline if it is enclosed in a quote.
> > I *have* seen monstrosities like fields that do not begin with the quote
> > character but then break into a quote, e.g.:
> >
> > 1,2,a,123"abc""def",6,7
>
>
> Karel Zak wrote:
>
>> The problem with CSV is that it will correctly work with new protocol
>> only. Because old versions of clients are newline sensitive. And CSV
>> can contains newline in by quotation marks defined attributes:
>>
>> "John", "Smith", "The White House
>> 1600 Pennsylva
Karel Zak <[EMAIL PROTECTED]> writes:
> And what \n in attibutes data in CSV? I think CSV format doesn't use
> some escape for newline char. It means psql with \copy cannot be sure
> with CSV.
I think CSV only allows embedded newlines that are either escaped, or
inside quotes. COPY doesn'
I wrote:
Fernando Nasser wrote:
[snip re multiline CSV fields]
I have never seen such a beast,
Export from a spreadsheet where people have formated the cell with
the address on it.
Well, I just tried with OpenOffice on my RH9 box, and it translated
the line breaks in the cell into spaces in
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> There are some wrinkles, though, concerning the interaction of CSV's
> notion of escaping and COPY's notion of escaping. If someone want to
> undertake this I can flesh those out in a further email.
Please do that, so that the info is in the archives
Fernando Nasser wrote:
Andrew Dunstan wrote:
Karel Zak wrote:
The problem with CSV is that it will correctly work with new protocol
only. Because old versions of clients are newline sensitive. And CSV
can contains newline in by quotation marks defined attributes:
"John", "Smith", "The White Ho
Karel Zak <[EMAIL PROTECTED]> writes:
> The problem with CSV is that it will correctly work with new protocol
> only. Because old versions of clients are newline sensitive.
Why? The client-side code doesn't have any real say over the meaning of
the data, at least not in psql-class clients.
On Fri, Mar 19, 2004 at 09:39:58AM -0500, Tom Lane wrote:
> Karel Zak <[EMAIL PROTECTED]> writes:
> >>> It's pity that main idea of current COPY is based on separated lines
> >>> and it is not more common interface for streaming data between FE and BE.
> >>
> >> Yeah, that was another concern I
Andrew Dunstan wrote:
Karel Zak wrote:
The problem with CSV is that it will correctly work with new protocol
only. Because old versions of clients are newline sensitive. And CSV
can contains newline in by quotation marks defined attributes:
"John", "Smith", "The White House
1600 Pennsylvani
Karel Zak <[EMAIL PROTECTED]> writes:
>>> It's pity that main idea of current COPY is based on separated lines
>>> and it is not more common interface for streaming data between FE and BE.
>>
>> Yeah, that was another concern I had. This API would let the formatter
>> control line-level layout
Karel Zak wrote:
The problem with CSV is that it will correctly work with new protocol
only. Because old versions of clients are newline sensitive. And CSV
can contains newline in by quotation marks defined attributes:
"John", "Smith", "The White House
1600 Pennsylvania Avenue NW
Washington
[EMAIL PROTECTED] (Andrew Dunstan) writes:
> Karel Zak wrote:
>
>> Hi,
>>
>> in TODO is item: "* Allow dump/load of CSV format". I don't think
>> it's clean idea. Why CSV and why not something other? :-)
>>
>> A why not allow to users full control of the format by they own
>> function. It means som
On Thu, Mar 18, 2004 at 10:16:36AM -0500, Tom Lane wrote:
> Passing in a relation OID is probably a bad idea anyway, as it ties this
> API to the assumption that COPY is only for complete relations. There's
> been talk before of allowing a SELECT result to be presented via the
> COPY protocol, for
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I could go with that too. The question here is do we have any popular
>> use-cases that aren't solved by that extension, but could be solved by
>> simple user-level data formatting functions?
> (I can't believe I'm s
Tom Lane <[EMAIL PROTECTED]> writes:
> I could go with that too. The question here is do we have any popular
> use-cases that aren't solved by that extension, but could be solved by
> simple user-level data formatting functions? I'm not real eager to add
> such a feature as an "if we build it t
And, BTW, I deal with CSV *all the time* for my insurance clients, and I can
tell you that that format hasn't changed in 20 years. We can hard-code it
if it's easier.
Well many of my clients consider CSV "Character Separated Value" not
Comma... Thus I get data like this:
"Hello","Good Bye"
He
Karel, Andrew, Fernando:
> On Wed, Mar 17, 2004 at 11:02:38AM -0500, Tom Lane wrote:
> > Karel Zak <[EMAIL PROTECTED]> writes:
> > > The formatting function API can be pretty simple:
> > > text *my_copy_format(text *attrdata, int direction,
> > > int nattrs, int attr, oid attrtype,
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Lee Kindness wrote:
> >> To be honest this idea strikes me as overkill - over
> >> engineering.
> >>
> > I agree. My modest proposal for handling CSVs would be to extend the
> > DELIMITER parameter to allow up to 3 characters - sepa
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Lee Kindness wrote:
>> To be honest this idea strikes me as overkill - over
>> engineering.
>>
> I agree. My modest proposal for handling CSVs would be to extend the
> DELIMITER parameter to allow up to 3 characters - separator, quote and
> escape. Es
Karel Zak <[EMAIL PROTECTED]> writes:
>> On Wed, Mar 17, 2004 at 11:02:38AM -0500, Tom Lane wrote:
>>> Karel Zak <[EMAIL PROTECTED]> writes:
This seems like it could only reasonably be implemented as a C function.
>>
>> Why? I said it's pseudo code. It should use standard fmgr API like
>> eve
Andrew Dunstan wrote:
> Lee Kindness wrote:
>
> >To be honest this idea strikes me as overkill - over
> >engineering. While there is a clear need for proper CSV import
> >(i.e. just setting DELIMITER to ',' doesn't work due to ','s in
> >strings) I cannot see how this would prove useful, or who wo
Lee Kindness wrote:
To be honest this idea strikes me as overkill - over
engineering. While there is a clear need for proper CSV import
(i.e. just setting DELIMITER to ',' doesn't work due to ','s in
strings) I cannot see how this would prove useful, or who would use
it?
I agree. My modest prop
On Thu, Mar 18, 2004 at 09:29:03AM +, Lee Kindness wrote:
> To be honest this idea strikes me as overkill - over
> engineering.
It was suggestion, maybe you're right :-)
> While i have done a lot of messing around reading/writing the binary
> format (and been stung by changes in that format
To be honest this idea strikes me as overkill - over
engineering. While there is a clear need for proper CSV import
(i.e. just setting DELIMITER to ',' doesn't work due to ','s in
strings) I cannot see how this would prove useful, or who would use
it?
While i have done a lot of messing around read
On Thu, Mar 18, 2004 at 07:48:40AM +0100, Karel Zak wrote:
> On Wed, Mar 17, 2004 at 11:02:38AM -0500, Tom Lane wrote:
> > Karel Zak <[EMAIL PROTECTED]> writes:
> > > The formatting function API can be pretty simple:
> > > text *my_copy_format(text *attrdata, int direction,
> > > in
On Wed, Mar 17, 2004 at 11:02:38AM -0500, Tom Lane wrote:
> Karel Zak <[EMAIL PROTECTED]> writes:
> > The formatting function API can be pretty simple:
> > text *my_copy_format(text *attrdata, int direction,
> > int nattrs, int attr, oid attrtype, oid relation)
>
> This seems like
I deal with this daily in a cygwin environment. I wrote a simple c++
program where I hardcoded the input file name/location and output file
name/location. I strip the quotation marks out where they are used for
identifying text fields and change the comma's used as CSV's to pipes.
I use a comb
That is why I suggested providing a pre-written/pre-compiled/installed
function for CSV (call it CSV?). Advanced users could still write
their own as people can write many other things if they know their ways.
As someone who just went through a whole truckload of crap getting
delimited file
Tom Lane wrote:
Karel Zak <[EMAIL PROTECTED]> writes:
The formatting function API can be pretty simple:
text *my_copy_format(text *attrdata, int direction,
int nattrs, int attr, oid attrtype, oid relation)
This seems like it could only reasonably be implemented as a C function.
I ca
Karel Zak wrote:
Hi,
in TODO is item: "* Allow dump/load of CSV format". I don't think
it's clean idea. Why CSV and why not something other? :-)
A why not allow to users full control of the format by they own
function. It means something like:
COPY tablename [ ( column [, ...] ) ]
TO { 'fil
Karel Zak <[EMAIL PROTECTED]> writes:
> The formatting function API can be pretty simple:
> text *my_copy_format(text *attrdata, int direction,
> int nattrs, int attr, oid attrtype, oid relation)
This seems like it could only reasonably be implemented as a C function.
I can't reall
Hans-Jürgen Schönig wrote:
Karel Zak wrote:
Hi,
in TODO is item: "* Allow dump/load of CSV format". I don't think
it's clean idea. Why CSV and why not something other? :-)
A why not allow to users full control of the format by they own
function. It means something like:
COPY tablename [ (
Karel Zak wrote:
Hi,
in TODO is item: "* Allow dump/load of CSV format". I don't think
it's clean idea. Why CSV and why not something other? :-)
A why not allow to users full control of the format by they own
function. It means something like:
COPY tablename [ ( column [, ...] ) ]
T
Hi,
in TODO is item: "* Allow dump/load of CSV format". I don't think
it's clean idea. Why CSV and why not something other? :-)
A why not allow to users full control of the format by they own
function. It means something like:
COPY tablename [ ( column [, ...] ) ]
TO { 'filename' |
39 matches
Mail list logo
