On Wed, Mar 2, 2016 at 2:44 PM, Joe Conway <m...@joeconway.com> wrote:
> On 03/02/2016 12:54 PM, Stephen Frost wrote: > > * Joe Conway (m...@joeconway.com) wrote: > >> On 03/01/2016 08:00 AM, Tom Lane wrote: > >>> Yes, we'd need some way to mark non-null ACLs as being "built-in > >>> defaults". I do not see the need to have SQL syntax supporting that > >>> though. > >> > >> I was thinking the supporting syntax might be used by extensions, for > >> example. > > > > I tend to agree with Tom that we don't really need SQL syntax for this. > > > I don't see any reason it couldn't be used by extensions also, though > > we'd have to do a bit more work on pg_dump to make it actually dump > > out any non-default ACLs for extension-owned objects. > > Without any syntax, what does the extension do, directly insert into > this special catalog table? > > The desire in the thread I linked was for the user, not the extension, to alter the permissions. In that context (and possibly here as well) PostgreSQL would (somehow?) recognize the target as being special and thus requiring adding or updating an entry into the supplemental catalog table when the usual GRANT/REVOKE SQL command is issued. In effect any object dependent upon an EXTENSION or that already exists in this special catalog table would need to have the supplemental procedure executed. David J.
