> > No I won't. As explained, I would return a tuple as is, just
> > with the LONG reference information. It will only, but then
> > allways again, be expanded if needed to compare, store again
> > or beeing output to the client. This "allways again" is one
> > of my drawbacks against your "treating all varsize pushable"
> > concept. In one of my early projects, I had to manage a
> > microVax for a year, and I love systems that can be fine
> > tuned since then, really! Auto detection is a nice feature,
> > but if that failes and you don't have any override option,
> > you're hosed.
>
> I am confused here. With my code, you only have to:
>
> add code to write/read from long tables
> add code to expand long values in varlen access routines
> add code to heap_insert() to move data to long tables
> add code to heap_delete() to invalidate long tuples
Add code to expand long values in varlen access routines,
you're joking - no?
How many functions are there, called via the fmgr with a
Datum as argument, and only knowing by themself (and a system
catalog) that they receive a variable length attribute?
So you would better do the fetching in the fmgr. Then again,
there are many places in the code (and possibly in user
extensions too), that call builtin functions like textout()
directly, passing it the Datum they got from somewhere.
I can understand why you would like to automatically pull out
varsize values as needed. But I see really a bunch of
problems coming with it.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
