Re: dealing with extension dependencies that aren't quite 'e'

Abhijit Menon-Sen wrote:
> At 2016-01-18 11:08:19 +0530, ams(at)2ndQuadrant(dot)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