From: | "Vadim B(dot) Mikheev" <vadim(at)sable(dot)krasnoyarsk(dot)su> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | PostgreSQL-development <hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Re: varchar() troubles (fwd) |
Date: | 1998-01-14 07:09:35 |
Message-ID: | 34BC64AF.CDD645C4@sable.krasnoyarsk.su |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | James Hughes | 1998-01-14 12:25:09 | Re: [HACKERS] grant still broken |
Previous Message | Peter T Mount | 1998-01-14 07:07:58 | Re: [HACKERS] Suggest a pg_privileges table |