From: | David Hartwig <daveh(at)insightdist(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] vlen in libpq using user defined data type |
Date: | 1998-09-10 21:03:43 |
Message-ID: | 35F83EAF.94F7410@insightdist.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Problem resolve. Hacker malfunction.
David Hartwig wrote:
> Tom Lane wrote:
>
> > David Hartwig <daveh(at)insightdist(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | Brook Milligan | 1998-09-10 23:13:07 | Re: [HACKERS] regression test errors: netbsd 1.3.2/i386 |
Previous Message | Taral | 1998-09-10 20:09:50 | pg_user backtrace -- with ElectricFence (looks useful :) |