Re: [HACKERS] LONG varsize - how to go on

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) #