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)  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: todd brandys
Дата:
Сообщение: Suggest a pg_privileges table
Следующее
От: Peter T Mount
Дата:
Сообщение: Re: [HACKERS] Re: New pg_pwd patch and stuff