Bruce Momjian wrote:
> > What I want to implement for now, is to store extended
> > VARLENA attributes into a regular (but other relkind)
> > relation with the Oid key as discussed. That will cause
> > minimum changes to VACUUM. If storage/retrieval of attributes
> > is encapsulated right, it could get replaced by something
> > different at any time in the future when we have enough
> > experience with this new technique.
>
> Good. I recommend calling it pg_* so it is automatically excluded from
> client table lists.
Additionally, exclude them from psql's \dS by looking at the
relkind. And for security reasons, disable regular SELECT for
non-superusers. Also, psql's \d should list the "secondary"
relation name after indices. But that's all stuff far away.
> >
> > Christof Petig and me then could start implementing it, using
> > lztext with locally disabled compression feature for the
>
> I would recommand having compression disabled by default, and enabled by
> the user.
Missed me here. I wanted to abuse lztext during development,
having that only beeing considered for move off at all to get
the in place tuple modification going. Then add all the other
varsize types (there are 12 plus arrays currently) to have
only one source of errors.
> OK, so we are going to see this after 7.0 is released, which is fine. I
> understand the concern about all the accesses to VARDATA() inside the
> code. That will clearly be difficult.
Seems so.
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) #
