Thread: vlen in libpq using user defined data type
I have come across a situation with 6.4 which has rendered at least some of my home made data types unusable. Specifically, the data type, accntnum, is a General Ledger account number type. (i.e. 9999-99 format) It is stored internally as an 4 byte integer; it is used externally as a string and passed by reference internally. An IP data type may be handled in a similar way. I had no problems at 6.3.2. 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. Did something changed in the way a string is constructed on the BE before sending to the FE to cause this? Have the basic semantics changed (intentionally or unintentionally) for the establishment of data types? Any assistance is appreciated.
> I have come across a situation with 6.4 which has rendered at least some > of my home made data types unusable. Specifically, the data type, > accntnum, is a General Ledger account number type. (i.e. 9999-99 > format) It is stored internally as an 4 byte integer; it is used > externally as a string and passed by reference internally. An IP data > type may be handled in a similar way. I had no problems at 6.3.2. > > 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. > > Did something changed in the way a string is constructed on the BE > before sending to the FE to cause this? > > Have the basic semantics changed (intentionally or unintentionally) for > the establishment of data types? Just reported today by another user. Tom Lane is working on this. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
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?
regards, tom lane
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?
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?