Re: [HACKERS] Re: varchar() troubles (fwd)
От | Vadim B. Mikheev |
---|---|
Тема | Re: [HACKERS] Re: varchar() troubles (fwd) |
Дата | |
Msg-id | 34BC64AF.CDD645C4@sable.krasnoyarsk.su обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: varchar() troubles (fwd) (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Re: varchar() troubles (fwd)
|
Список | pgsql-hackers |
Bruce Momjian wrote: > > > > > I have found that ExecEvalVar() uses a descriptor that has the attr > > length set to the maximum, instead of -1. The ExecTypeFromTL() comment ... > > Vadim, can you look at this for me. If you set a break at ExecEvalVar > before executing the SELECT, you will see its > tupledescriptor->attrs[0].attlen is the max length, and not -1 as it > should be. > > I can't figure out where that is getting set. Can you also check the > other tupledescriptor initializations to see they have the -1 for > varchar too. I am stumped. Why attlen should be -1 ? attlen in pg_attribute for v in table t is 84, why run-time attlen should be -1 ? How else maxlen constraint could be checked ? IMHO, you have to change heap_getattr() to check is atttype == VARCHAROID and use vl_len if yes. Also, other places where attlen is used must be changed too - e.g. ExecEvalVar(): { len = tuple_type->attrs[attnum - 1]->attlen; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ byval = tuple_type->attrs[attnum - 1]->attbyval ? true : false; } execConstByVal = byval; execConstLen = len; ^^^^^^^^^^^^^^^^^^ - used in nodeHash.c Vadim
В списке pgsql-hackers по дате отправления: