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.


---------------------------(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

Reply via email to