From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | vadim(at)sable(dot)krasnoyarsk(dot)su (Vadim B(dot) Mikheev) |
Cc: | hackers(at)postgreSQL(dot)org (PostgreSQL-development) |
Subject: | Re: [HACKERS] Re: varchar() troubles (fwd) |
Date: | 1998-01-16 05:05:03 |
Message-ID: | 199801160505.AAA06221@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Forwarded message:
> > 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
> >
>
> The major problem is that TupleDesc comes from several places, and
> attlen means several things.
>
> There are some cases where TupleDesc (int numatt, Attrs[]) is created
> on-the-fly (tupdesc.c), and the attlen is the length of the type. In
> other cases, we get attlen from opening the relation, heap_open(), and
> in these cases it is the length as defined for the particular attribute.
>
> Certainly a bad situation. I am not sure about a fix.
OK, here is a temporary fix to the problem. It does the heap_open(),
then replaces the attrs for VARCHAR with attlen of -1. You can't just
change the field, because the data is in a cache and you are just
returned a pointer.
Can I add an 'attdeflen' for "attributed defined length" field to
pg_attribute, and change the attlen references needed to the new field?
This is the only proper way to fix it.
---------------------------------------------------------------------------
*** ./backend/executor/execAmi.c.orig Thu Jan 15 22:42:13 1998
--- ./backend/executor/execAmi.c Thu Jan 15 23:54:37 1998
***************
*** 42,47 ****
--- 42,48 ----
#include "access/genam.h"
#include "access/heapam.h"
#include "catalog/heap.h"
+ #include "catalog/pg_type.h"
static Pointer
ExecBeginScan(Relation relation, int nkeys, ScanKey skeys,
***************
*** 124,129 ****
--- 125,155 ----
if (relation == NULL)
elog(DEBUG, "ExecOpenR: relation == NULL, heap_open failed.");
+ {
+ int i;
+ Relation trel = palloc(sizeof(RelationData));
+ TupleDesc tdesc = palloc(sizeof(struct tupleDesc));
+ AttributeTupleForm *tatt =
+ palloc(sizeof(AttributeTupleForm*)*relation->rd_att->natts);
+
+ memcpy(trel, relation, sizeof(RelationData));
+ memcpy(tdesc, relation->rd_att, sizeof(struct tupleDesc));
+ trel->rd_att = tdesc;
+ tdesc->attrs = tatt;
+
+ for (i = 0; i < relation->rd_att->natts; i++)
+ {
+ if (relation->rd_att->attrs[i]->atttypid != VARCHAROID)
+ tdesc->attrs[i] = relation->rd_att->attrs[i];
+ else
+ {
+ tdesc->attrs[i] = palloc(sizeof(FormData_pg_attribute));
+ memcpy(tdesc->attrs[i], relation->rd_att->attrs[i],
+ sizeof(FormData_pg_attribute));
+ tdesc->attrs[i]->attlen = -1;
+ }
+ }
+ }
return relation;
}
--
Bruce Momjian
maillist(at)candle(dot)pha(dot)pa(dot)us
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas G. Lockhart | 1998-01-16 05:26:08 | Re: [HACKERS] Re: varchar() troubles (fwd) |
Previous Message | D'Arcy J.M. Cain | 1998-01-16 04:21:30 | Re: [HACKERS] CBAC (content based access control), OIDs, auto fields |