Christoph Zwerschke wrote:
> > Function updated. I assume you wanted to replace pg_inserttable in
> > pgmodule.c with your version, which I have done.
>
> Yes, thank you. I'm using the patched function intensely in a project for
> nearly a year so there shouldn't be any great bugs in it.
>
> > As for your comment about COPY BINARY, binary is not portable between
> > machines so I can't see why we would perfer that. Is that something
> > that we would never do between machines?
>
> You are right, as pg_inserttable is running on the client side, it does not
> know which binary format to provide for the server. However, I understand
> the format might become machine independant in the future (the new file
> format since 7.1 already indicates the integer layout etc.) Also,
> pg_inserttable could check whether the database host of the connection is
> the localhost and switch to binary mode only in that case. I just had the
> idea that this could reduce the number of conversions and speed up the
> process a lot. For instance, a Python floating point number will be
> converted three times, first with PyFloat_AS_DOUBLE to a C double, then with
> sprintf("%g") to a string representation and then again in PostgreSQL "COPY
> TO" to PostgreSQL double precision. My idea was to convert the Python float
> directly to a PostgreSQL float.
There are no concrete plans for a binary-portable COPY format, and in
fact if we did one it would probably have the same overhead as ASCII
does now.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
