Skip site navigation (1) Skip section navigation (2)

Re: Hmm, should ACL[] be toastable?

From: JanWieck(at)t-online(dot)de (Jan Wieck)
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hmm, should ACL[] be toastable?
Date: 2000-07-29 23:23:02
Message-ID: 200007292323.BAA03729@hot.jw.home (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> I notice that ACL lists are represented as arrays of aclitem, which
> means they are now theoretically toastable.  (In practice, I haven't
> finished fixing all the routines that touch ACLs, but will soon.)
>
> Do we need long lists of ACLs?  If so, is there any danger in giving
> pg_class a toast relation?  It's a tad closer to the heart of the
> system than pg_rewrite, so I'm not quite sure if that will work or
> not.  Jan?

    In theory it should work, in practice, I don't know.

    Since pg_class is really close to the heart of the system, it
    is created a little different during bootstrap. This  causes,
    that  setting  relacl  to  storage  'x' doesn't automatically
    create  a  toast  relation  for  it  during  bootstrap.   And
    therefore,  the  toaster  should  only try to compress, never
    move out (to where?).

    Someone could later create such  a  toast  table  with  ALTER
    TABLE  ...   if  he wants to give it a try. And we could warn
    him not to do so before we really stress tested it.

    Is that a compromise?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #



In response to

pgsql-hackers by date

Next:From: Philip WarnerDate: 2000-07-30 00:08:03
Subject: Re: pg_dump + function/table hierarchy
Previous:From: Kovacs Zoltan SandorDate: 2000-07-29 19:18:17
Subject: pg_dump + function/table hierarchy

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group