Re: dealing with extension dependencies that aren't quite 'e' - Mailing list pgsql-hackers

From Abhijit Menon-Sen
Subject Re: dealing with extension dependencies that aren't quite 'e'
Date
Msg-id 20160301012745.GA11489@toroid.org
Whole thread Raw
In response to Re: dealing with extension dependencies that aren't quite 'e'  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Responses Re: dealing with extension dependencies that aren't quite 'e'
Re: dealing with extension dependencies that aren't quite 'e'
List pgsql-hackers
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?

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.

Comments welcome. I'll add this patch to the CF.

-- Abhijit

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: create opclass documentation outdated
Next
From: Amit Langote
Date:
Subject: Re: Proposal: "Causal reads" mode for load balancing reads without stale data