From: | Lee Kindness <lkindness(at)csl(dot)co(dot)uk> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Lee Kindness <lkindness(at)csl(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 7.4 COPY BINARY Format Change |
Date: | 2003-08-04 16:44:27 |
Message-ID: | 16174.36203.260971.150595@kelvin.csl.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom,
Tom Lane writes:
> Lee Kindness <lkindness(at)csl(dot)co(dot)uk> writes:
> > However, is COPY BINARY meant/designed to be used as transfer or
> > backup mechanism?
>
> I think you're overlooking a key consideration: COPY BINARY is not
> an isolated feature anymore. By design it uses the same data
> representations as are used for binary query parameters and results
> in the rest of the 7.4 FE/BE protocol.
Yeah, what i've overlooked is that an implementation detail now forms
part of an external interface into PostgreSQL - this is a major
change.
> I could see some value in providing byte-swapping routines in libpq
> to convert between local and network representations for integers and
> floats. The underlying facilities (ntohl etc) are readily available,
> of course, but it's a small matter that is easy to get wrong.
>
> I'm not sure it's worth packaging up COPY BINARY logic per se. I think
> you'd end up with an API not materially simpler than dealing with the
> format directly. And I'm unconvinced it'd actually be used widely,
> whereas I do expect binary transfer of individual values to be common.
Would I be right is guessing a binary CURSOR would return in values in
the same format as a binary COPY, hence your expectation of more
individual transfers/conversions? Actually with the new FE/BE protocol
there is little call for the binary cursor now, yeah?
What I proposed in my email yesterday is really just completing the
new functions (PQnfields, PQputCopyData, PQgetCopyData and friends)
described at:
http://developer.postgresql.org/docs/postgres/libpq-copy.html
so they don't stop at just giving you a blob of binary data and saying
it has n fields - functions would be available to iterate over the
fields and get the data out in a format which is immediately
useful. Without this do you not think PQgetCopyData is of limited use
except for being used by psql (which I guess isn't using it yet). Same
for the writing functions.
This is slightly different from my earlier example (on the connection
rather than file-based) but functionally similar.
BTW, do you have any examples of using PQgetCopyData - none in the
source and can't find anything with Google.
Regards, Lee.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-08-04 16:50:31 | Re: Thread-safe configuration option appears to |
Previous Message | Josh Berkus | 2003-08-04 16:42:03 | Re: "truncate all"? |
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2003-08-04 17:11:06 | Re: [HACKERS] statement level trigger causes pltcl, plpython |
Previous Message | Peter Eisentraut | 2003-08-04 14:01:04 | Re: Updated french po files |