COPY formatting

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