On Dec 6, 2007 11:58 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I want to buy into the idea that libpq should know explicitly about each
> and every backend datatype.
I don' t necessarily agree with this. First of all, the server gives
you an oid for the column which introduces the dependency...th
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
Here is the lastest pgparam patch. It is patched against a fresh
checkout on 2007-12-05.
What is this for? Why is it a good idea? It appears to be a fairly
enormous increase in the size of libpq's API, and I really don't think
I wan
Andrew Chernow <[EMAIL PROTECTED]> writes:
> Here is the lastest pgparam patch. It is patched against a fresh
> checkout on 2007-12-05.
What is this for? Why is it a good idea? It appears to be a fairly
enormous increase in the size of libpq's API, and I really don't think
I want to buy into t
Merlin Moncure wrote:
On Dec 5, 2007 2:44 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Andrew Chernow escribió:
Also changed PQputint8's prototype. Previously, it was using a void* as
the value argument, due to a lack of a portable 64-bit type in libpq. We
found an intersting way around this
On Dec 5, 2007 2:44 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Andrew Chernow escribió:
>
> > Also changed PQputint8's prototype. Previously, it was using a void* as
> > the value argument, due to a lack of a portable 64-bit type in libpq. We
> > found an intersting way around this by using m
Andrew Chernow escribió:
> Also changed PQputint8's prototype. Previously, it was using a void* as
> the value argument, due to a lack of a portable 64-bit type in libpq. We
> found an intersting way around this by using macro and variable argument
> tricks.
I didn't read the patch, but varia
