Re: [HACKERS] Re: varchar() troubles (fwd)

> 
> > 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.
> 

> Bruce, does your "temporary fix" seem to repair all known problems
with varchar()? If so, would you be interested in > holding off on a
"proper fix" and coming back to it after v6.3 is released? At that time,
we can try solving the general > problem of retaining column-specific
attributes, such as your max len for varchar, declared dimensions for
arrays, and > numeric() and decimal() types. Or, if you have time to try
a solution now _and_ come back to it later... >  >                      

[Those wide post really are difficult.]

I don't think my solution is perfect or complete.  I only caught one
group of heap_open calls used in the executor.  I could funnel all of
them through this patched function, but I can imagine there would be
ones I would miss.  Once the structure is gotten from the cache, it
seems to fly around the executor code quite freely, and it is hard to
know when a tuple descriptor is being created, if it is being used for
data creation or data reference.  attlen references are much clearer in
their intent.

If I add a new field type to FormData_pg_attribute, I can then check
each attlen reference, and check if it is trying to move through the
on-disk storage (attlen/typlen) or create a new/modify an entry
(attdeflen).

How much time I have depends on what Vadim needs me to do for
subselects.


-- 
Bruce Momjian
maillist@candle.pha.pa.us