On Dec 8, 2007 6:50 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Please note that I'm not saying that fixing that issue means the patch
> > is acceptable. Personally I'm not sure that this is a worthy goal you
> > are pursuing here. Wouldn't it be a good idea to propose the feature
> > first and write the code later?
>
> Indeed. For starters, if we are going to try to provide serious
> support in libpq for binary-format parameters, it probably ought to
> cover more than just integers. OTOH, I think we've already seen
> where that line of thought leads, and it looks pretty ugly too:
> http://archives.postgresql.org/pgsql-patches/2007-12/msg00014.php
>
> Anyway, I'd like to see a design discussion about what any libpq API
> changes in this area ought to look like, rather than having it be
> determined by who can submit the quickest-and-dirtiest patch.
A major overhaul of this patch is coming...we are addressing some of
the issues that were raised. I think that this is an important issue
that needs to be solved. Dealing with arrays is a complete mess, and
many other things are more difficult than they have to be. User
defined types are problem as well, and marshaling everything into text
is always a good solution.
In the long term, my opinion is that postgresql types have to be
converted into a more pluggable interface that is available into both
the client and the server. It doesn't really make sense to
reimplement the send/receive routines in both the client and the
server...and the patch that we proposed (ditto the OP) did not really
leave room for this in the future. That said, I strongly feel that
libpq should in some fashion do a better job in handling binary data
than it currently does.
Andrew and I are taking this into consideration and will submit a
proposal that we hope that should hopefully deal with things in a more
acceptable way. We understand the ramifications of extending the
libpq api.
merlin
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
