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 reading/writing the binary
format (and been stung by changes in that format) if you are using
this format then you're 99% likely to be in control of the
incoming/outgoing data and thus able to format to your wishes outwith
COPY.
Something else in the TODO regarding COPY is XML import/export, and
for this to be supported in your proposed implementation the function
would need to be passed in a heap more information.
L.
Karel Zak writes:> > Hi,> > in TODO is item: "* Allow dump/load of CSV format". I don't think> it's clean idea. Why
CSVand why not something other? :-) > > A why not allow to users full control of the format by they own> function. It
meanssomething like:> > COPY tablename [ ( column [, ...] ) ]> TO { 'filename' | STDOUT }> [ [ WITH ] >
[ BINARY ]> [ OIDS ]> [ DELIMITER [ AS ] 'delimiter' ]> [ NULL [ AS ] 'null string'
]> [ FORMAT funcname ] ]> ^^^^^^^^^^^^^^^^> > The
formattingfunction API can be pretty simple:> > text *my_copy_format(text *attrdata, int direction, > int
nattrs,int attr, oid attrtype, oid relation)> > -- it's pseudocode of course, it should be use standard fmgr>
interface.> > It's probably interesting for non-binary COPY version.> > Comments?> > Karel