Tom Lane wrote:
> Adriaan Joubert <a.joubert@albourne.com> writes:
> >> Such as? IIRC, the reason we disabled it was precisely that there was
> >> no support on the client side. (What's worse, there's no support in
> >> the FE/BE protocol either. I don't see how you could have made this
> >> work...)
>
> > I issued a 'copy binary <table> from stdin;' and then sent the data with
> > PQputnbytes
>
> How did you get out of COPY state? In binary mode CopyFrom will only
> recognize EOF as end of data, and there's no provision in the FE/BE
> protocol for making it see an EOF. You'd have had to break the
> connection to get out of that --- and I'd have expected the loss of
> connection to cause a transaction abort, preventing your data from
> getting committed. (If it didn't abort, that's a bug that needs to be
> fixed... if the line drops halfway through a copy, you don't want it
> to commit do you?)
Don't know. I first sent the length of the binary buffer, then the buffer (I
just stored the whole thing in an STL vector) and PQendcopy to terminate it.
But, as you said, libpq is probably not the right way to go about it. Also,
the docs for the binary structure were not quite correct, but it took only a
little bit of fiddling to get the structure right. I could not find the
description of the binary structure back in the current docs on
postgresql.org, so I guess this really has been ripped out.
>
> A CORBA-based replacement protocol has been discussed seriously, though
> I haven't noticed any work getting done on it lately. Feel free to
> pitch in if you think it's a good idea.
Yes, I've been looking through the mailing list. Problem is to settle on a
CORBA system that runs everywhere. And it is much more natural to program
CORBA in C++, but if I see the problems people have had just compiling the C++
interface to postgres, this looks like a no-go. I'll look around at the
various bits and pieces floating around the net.
If anybody is working on a CORBA interface to postgres, please let me know!
Adriaan
