Re: [HACKERS] vlen in libpq using user defined data type
От | David Hartwig |
---|---|
Тема | Re: [HACKERS] vlen in libpq using user defined data type |
Дата | |
Msg-id | 35F83EAF.94F7410@insightdist.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] vlen in libpq using user defined data type (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Problem resolve. Hacker malfunction. David Hartwig wrote: > 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 по дате отправления: