From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Abhijit Menon-Sen <ams@2ndQuadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: dealing with extension dependencies that aren't quite 'e'
Date: Sat, 19 Mar 2016 17:46:25 -0300
Message-ID: <20160319204625.GA318727@alvherre.pgsql> (raw)
In-Reply-To: <20160301012745.GA11489@toroid.org>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Abhijit Menon-Sen wrote:
> At 2016-01-18 11:08:19 +0530, ams@2ndQuadrant.com wrote:
> >
> > I'm proposing to address a part of that problem by allowing extension
> > dependencies to be explicitly declared for functions and objects
> > created either by a user or dynamically by the extension itself—things
> > that need the extension to function, but aren't a part of it.
>
> I didn't hear any further suggestions, so here's a patch for discussion.
>
> 1. This adds the 'x'/DEPENDENCY_AUTO_EXTENSION type.
> 2. This adds an 'ALTER FUNCTION … ADD DEPENDENT FUNCTION …' command.
>
> I split up the two because we may want the new dependency type without
> going to the trouble of adding a new command. Maybe extension authors
> should just insert an 'x' row into pg_depend directly?
Surely not. I don't think the first patch is acceptable standalone --
we need both things together.
> I was inclined to implement it using ALTER FUNCTION, but AlterFunction()
> is focused on altering the pg_proc entry for a function, so the new code
> didn't fit. Ultimately, ExecAlterExtensionContentsStmt() was the closest
> match, so that's where I did it.
Right, but see AlterObjectOwner() or ExecAlterObjectSchemaStmt() whereby
an arbitrary object has some property altered. I think that's a closer
model for this. It's still not quite the same, because those two
functions are still about modifying an object's catalog row rather than
messing with things outside of its own catalog. But in reality,
pg_depend handling is mixed up with other changes all over the place.
Anyway I think this should be something along the lines of
ALTER FUNCTION foo() DEPENDS ON EXTENSION bar;
because it's really that object's behavior that you're modifying, not
the extension's. Perhaps we could use the precedent that columns "own"
sequences when they use them in their default value, which would lead to
ALTER FUNCTION foo() OWNED BY EXTENSION bar;
(which might cause a problem when you want to mark sequences as
dependant on extensions, because we already have OWNED BY for them. But
since EXTENSION is already a reserved word, maybe it's fine.)
I wondered whether it's right to be focusing solely on extensions as
being possible targets of such dependencies. It's true that extensions
are the only "object containers" we have, but perhaps you want to mark a
function as dependant on some view, type, or another function, for
instance. Another argument to focus only on extensions is that pg_dump
knows specifically about extensions for supressing objects to dump, and
we don't have any other object type doing the same kind of thing; so
perhaps extensions-only is fine. I'm undecided on this.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@2ndquadrant.com, ams@2ndQuadrant.com
Subject: Re: dealing with extension dependencies that aren't quite 'e'
In-Reply-To: <20160319204625.GA318727@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox