Greg Stark <[EMAIL PROTECTED]> writes:
> Is there anything technically hard in adding this functionality to libpq? It
> looks like it's just mechanically adding more entry points to existing code.
Well, (a) I ran out of time, and (b) I wasn't sure what the most
convenient API would be. Should we create something that packages
together a Parse and a Describe Statement, or expose those as
separate things?
There's surely no technical difficulty once you've got some consensus
on what the API should look like.
> The describe statement part could be much trickier but DBD::Pg doesn't really
> need that for basic functionality.
Doesn't it? I thought the problem was that they couldn't find out what
datatypes the parameters got resolved as. That may not be important
if they are happy with always shipping text strings, but if they want to
move over to using binary transmission of parameter values then they
gotta know the parameter types.
> I do wonder whether DBD::Pg is really best off using libpq.
I was wondering that myself. Would they be able to implement a
pure-Perl driver if they ginned up their own protocol code?
It'd be a lot of work, of course, so I can understand that they
might not feel it's worth the trouble.
> From what I'm reading now it seems the "read every record before
> returning" behaviour is rooted in the libpq interface.
Right. Again that's probably something that could be handled by
exposing more/different API, but no one has stepped up to design it.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
