Обсуждение: "create function... depends on extension..." not supported. Why?

Note: I’m asking because the answer to the question “Why isn’t X supported?” is always useful. For example, if
supportingit would imply a logical impossibility that I’m too slow to spot, it helps me when someone explains what I
failedto realize. Equally, it helps me to know when the answer is “It’s just a historical accident. It could have been
supported.But, now that it isn’t, it doesn’t seem worth the effort to bridge that gap” because this shows me that my
existingmental model is sound. 

The background for my question here is that among the documented changes that you can make using “alter function”

https://www.postgresql.org/docs/current/sql-alterfunction.html

you can specify all of them at “create time” too (but possibly, like “owner”, only implicitly) except for “depends on
extension”.When you know in advance that you want to set this property, you need two statements: 

create function f()
 returns int
 language plpgsql
as $body$
begin
 return 42;
end;
$body$;

alter function f()
depends on extension pgcrypto;

Why is this not supported:

create function f()
 returns int
 language plpgsql
 depends on extension pgcrypto
as $body$
begin
 return 42;
end;
$body$;

david.g.johnston@gmail.com wrote:

bryn@yugabyte.com wrote:

Note: I’m asking because the answer to the question “Why isn’t X supported?” is always useful. For example, if supporting it would imply a logical impossibility that I’m too slow to spot, it helps me when someone explains what I failed to realize. Equally, it helps me to know when the answer is “It’s just a historical accident. It could have been supported. But, now that it isn’t, it doesn’t seem worth the effort to bridge that gap” because this shows me that my existing mental model is sound.

Here is the commit that brought the feature into existence (it includes a link to the archives for discussion from which you can read or infer things).

https://github.com/postgres/postgres/commit/f2fcad27d59c8e5c48f8fa0a96c8355e40f24273

Bryn Llewellyn <bryn@yugabyte.com> writes:
> The discussion has diverging threads and very many turns. I think that I managed to skim through the entire tree. As
Iread it, the discussion was entirely about the semantics of the proposed dependency of a function (or procedure) upon
anextension. The idea to establish such a dependency using “alter function” came up quite early in the discussion. It
seemsthat establishing it at “create function” time was never considered. 

Probably not.  Just for the record, it's not true that CREATE and ALTER
always have the same set of options.  An obvious counterexample is that
you can't set the owner to someone different from yourself during CREATE.
There may be others.

I suppose that "DEPENDS ON EXTENSION" was modeled after the commands
to control extension membership, which likewise exist only in ALTER
form because CREATE's behavior for that is hard-wired.  If you wanted
to hand-wave a lot, you could maybe claim that ownership and extension
membership/dependency are similar kinds of relationships and so it
makes sense that the command structures for manipulating them are
similar.  But TBH that would probably be reverse-engineering an
explanation.  I think that "we didn't bother" is more nearly the
situation.

            regards, tom lane

tgl@sss.pgh.pa.us wrote:

bryn@yugabyte.com wrote:

The discussion has diverging threads and very many turns. I think that I managed to skim through the entire tree. As I read it, the discussion was entirely about the semantics of the proposed dependency of a function (or procedure) upon an extension. The idea to establish such a dependency using “alter function” came up quite early in the discussion. It seems that establishing it at “create function” time was never considered.

Probably not.  Just for the record, it's not true that CREATE and ALTER always have the same set of options.  An obvious counterexample is that you can't set the owner to someone different from yourself during CREATE. There may be others.

I suppose that "DEPENDS ON EXTENSION" was modeled after the commands to control extension membership, which likewise exist only in ALTER form because CREATE's behavior for that is hard-wired.  If you wanted to hand-wave a lot, you could maybe claim that ownership and extension membership/dependency are similar kinds of relationships and so it makes sense that the command structures for manipulating them are similar.  But TBH that would probably be reverse-engineering an explanation.  I think that "we didn't bother" is more nearly the situation.

On 2022-Apr-26, Tom Lane wrote:

> I suppose that "DEPENDS ON EXTENSION" was modeled after the commands
> to control extension membership, which likewise exist only in ALTER
> form because CREATE's behavior for that is hard-wired.  If you wanted
> to hand-wave a lot, you could maybe claim that ownership and extension
> membership/dependency are similar kinds of relationships and so it
> makes sense that the command structures for manipulating them are
> similar.  But TBH that would probably be reverse-engineering an
> explanation.  I think that "we didn't bother" is more nearly the
> situation.

IIRC Abhijit and I discussed this point offline, and our conclusion was
that DEPENDS ON EXTENSION was not of general enough usefulness to
warrant support for it in CREATE FUNCTION -- keeping in mind that we
would need support for it in CREATE INDEX, CREATE TRIGGER, CREATE
MATERIALIZED VIEW as well.

It's probably not that much code.  The effort of writing the code wasn't
the barrier we were optimizing for, but rather for getting the whole
*idea* accepted.

If this feature is suddenly so useful as to *require* support in the
various CREATE commands, that is most satisfying to me and I volunteer
to reviewing patches that implement it.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> IIRC Abhijit and I discussed this point offline, and our conclusion was
> that DEPENDS ON EXTENSION was not of general enough usefulness to
> warrant support for it in CREATE FUNCTION -- keeping in mind that we
> would need support for it in CREATE INDEX, CREATE TRIGGER, CREATE
> MATERIALIZED VIEW as well.

Yeah.  Quite aside from the code bloat and grammar bloat, my main
fear about that would be the assumption that we could wedge a consistent
syntax for this into all those different sorts of CREATE commands.
At the very least we'd probably find ourselves having to make those
keywords more reserved than they are now.

            regards, tom lane