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 confused, but
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 say over
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
[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 something like:
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, DC
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 but it would
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 Pennsylvania
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 had. This API
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. I
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 House
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 in
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
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't
quote who=Andrew Dunstan
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
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 abcdef - abcdef
cheers
andrew
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
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
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,
int nattrs, int
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)
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
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 would use
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
every other
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. Escape would
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 - separator, quote and
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, oid
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
Hello
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 they
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 saying this,
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
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 [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 really
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 {
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
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
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
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 it could
36 matches
Mail list logo
