Re: [HACKERS] vlen in libpq using user defined data type - Mailing list pgsql-hackers

From David Hartwig
Subject Re: [HACKERS] vlen in libpq using user defined data type
Date
Msg-id 35F7F57F.FC149AED@insightdist.com
Whole thread Raw
In response to Re: [HACKERS] vlen in libpq using user defined data type  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

Tom Lane wrote:

> David Hartwig <daveh@insightdist.com> writes:
> > Anyway, as pqlib reads the string sent to it by the backend (a la psql),
> > it must first read the length of each string.  The problem is that the
> > length of the string for accntnum in some outrageously large number
> > which ultimately hangs psql.  BTW,  atttypemod = -1 and typlen = 4 in
> > the FE.
>
> Is this fixed by the patch I sent in last night?  Your description does
> not sound like what I would expect.  The bug I fixed was that PQfsize()
> would return 65535 instead of -1 for a varlen field.  But neither libpq
> nor psql make use of that value (which is why I hadn't noticed it was
> broken).  Are you using some other frontend code that does depend on
> PQfsize to return the right thing?
>

I am using psql.   I put some debug statements in libpq get this far.   If I
didn't mention it earlier, I put some log messages in my output function and
it shows no problems.  All the other functionality of my date type seems to
work.   Specifically, the index look up via the WHERE clause, and the input
function. work fine,

I just tried the patch without success.    I didn't think this was my problem
but it was worth a try.   Hacking away...

Does anyone know where (and/or how) the PQfsize is derived in the backend?


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] more on int8
Next
From: darcy@druid.net (D'Arcy J.M. Cain)
Date:
Subject: Re: [HACKERS] open 6.4 items