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

At 2016-04-05 18:45:58 -0300, alvhe...@2ndquadrant.com wrote: > > I changed the regression test a bit more, so please recheck. Looks good, thank you. -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

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

Alvaro Herrera wrote: > Abhijit Menon-Sen wrote: > > OK, thanks for the clarification. Here's the earlier patch, but with > > the relevant added docs and tests retained. > > I'd like to add indexes and materialized views to the set of objects > covered (functions and triggers). I'm already doing

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

Abhijit Menon-Sen wrote: > OK, thanks for the clarification. Here's the earlier patch, but with > the relevant added docs and tests retained. I'd like to add indexes and materialized views to the set of objects covered (functions and triggers). I'm already doing that, so no need to resubmit; it

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

OK, thanks for the clarification. Here's the earlier patch, but with the relevant added docs and tests retained. -- Abhijit >From dfb6ded15246ec65cc911864bfcff285eef1c4d4 Mon Sep 17 00:00:00 2001 From: Abhijit Menon-Sen Date: Tue, 5 Apr 2016 11:55:09 +0530 Subject:

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

Abhijit Menon-Sen wrote: > At 2016-04-05 12:33:56 +0530, a...@2ndquadrant.com wrote: > > > > Álvaro: I did document and test the extra types you added, but now > > that I think about it a bit more, it's hard to argue that it's useful > > to have a table, for example, depend on an extension.

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

At 2016-04-05 12:33:56 +0530, a...@2ndquadrant.com wrote: > > Álvaro: I did document and test the extra types you added, but now > that I think about it a bit more, it's hard to argue that it's useful > to have a table, for example, depend on an extension. There's really > nothing about a table

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

Álvaro: I did document and test the extra types you added, but now that I think about it a bit more, it's hard to argue that it's useful to have a table, for example, depend on an extension. There's really nothing about a table that "doesn't work without" an extension. -- Abhijit -- Sent via

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

Hi. Here's the updated patch. It fixes a couple of small problems, and includes documentation and tests (which I placed in a new file in src/test/modules/test_extensions, on Petr's advice). I wanted to post this before I went on to attempt any more grammar cleanups. Please let me know if there's

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

At 2016-04-04 18:55:03 -0300, alvhe...@2ndquadrant.com wrote: > > At this point I think we're missing user-level docs for the additional > clause in each ALTER command. Thanks for having a look. Now that you're happy with the grammar, I'll write the remaining docs and resubmit the patch later

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

Abhijit Menon-Sen wrote: > At 2016-03-29 10:15:51 -0400, da...@pgmasters.net wrote: > > > > Either way it looks like you need to post a patch with more > > documentation - do you know when you'll have that ready? > > Here it is. > > (I was actually looking for other potential callers, but I

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

Abhijit Menon-Sen wrote: > At 2016-03-29 10:15:51 -0400, da...@pgmasters.net wrote: > > > > Either way it looks like you need to post a patch with more > > documentation - do you know when you'll have that ready? > > Here it is. > > (I was actually looking for other potential callers, but I

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

At 2016-03-29 10:15:51 -0400, da...@pgmasters.net wrote: > > Either way it looks like you need to post a patch with more > documentation - do you know when you'll have that ready? Here it is. (I was actually looking for other potential callers, but I couldn't find any. There are some places that

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

Hi Abhijit, On 3/25/16 1:57 PM, Abhijit Menon-Sen wrote: Complete patch attached for reference, as before. (I know I haven't documented the function. I will go through the code to see if there are any other potential callers, but I wanted to share what I had already.) I'm not entirely sure

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

At 2016-03-24 22:48:51 +0530, a...@2ndquadrant.com wrote: > > > I think I would like to see code implement both alternatives to see > > which one is least ugly. Maybe a third idea will manifest itself > > upon seeing those. > > Here's the first one. ExecAlterObjectDependsStmt() looks like this:

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

At 2016-03-24 12:31:16 -0300, alvhe...@2ndquadrant.com wrote: > > In other words I think the conclusion here is that we must use > qualified_name in the new production rather than switching the old > production to any_name. Makes sense. > I think I would like to see code implement both

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

Robert Haas wrote: > On Wed, Mar 23, 2016 at 1:00 PM, Abhijit Menon-Sen > wrote: > > Now, the first part of this works fine. But with the second part, I get > > a reduce/reduce conflict if I use any_name. Here's an excerpt from the > > verbose bison output: > > > > State

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

On Wed, Mar 23, 2016 at 1:00 PM, Abhijit Menon-Sen wrote: > Now, the first part of this works fine. But with the second part, I get > a reduce/reduce conflict if I use any_name. Here's an excerpt from the > verbose bison output: > > State 2920 > > 1181

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

Hi. I implemented "ALTER FUNCTION … DEPENDS ON EXTENSION" using a new node (AlterObjectDependsStmt), and tried to add "ALTER TRIGGER … DEPENDS ON EXTENSION" (partly because I wanted to make sure the code could support multiple object types, partly because it's convenient in this particular use

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

At 2016-03-21 15:43:09 -0400, robertmh...@gmail.com wrote: > > I also think we should allow a function to depend on multiple > extensions, as Alvaro mentions downthread. I'm working on an updated patch, will post shortly. -- Abhijit -- Sent via pgsql-hackers mailing list

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

On Mon, Mar 21, 2016 at 7:19 AM, Abhijit Menon-Sen wrote: > At 2016-03-21 13:04:33 +0300, a.korot...@postgrespro.ru wrote: >> >> I'm not sure why we want to make new dependency type by ALTER FUNCTION >> command, not ALTER EXTENSION? > > It's a matter of semantics. It means

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

Abhijit Menon-Sen wrote: > + else if (strcmp(defel->defname, "extdepend") == 0) > + { > + if (*extdepend_item) > + goto duplicate_error; > + > + *extdepend_item = defel; > + } > else > return false; > I'm not sure I

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

At 2016-03-21 12:04:40 +0530, a...@2ndquadrant.com wrote: > > I'll write up a patch for this. Thanks for the suggestions. Here's a patch to implement ALTER FUNCTION x DEPENDS ON EXTENSION y. The changes to functioncmds.c:AlterFunction were less intrusive than I had originally feared. -- Abhijit

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

On Mon, Mar 21, 2016 at 2:19 PM, Abhijit Menon-Sen wrote: > At 2016-03-21 13:04:33 +0300, a.korot...@postgrespro.ru wrote: > > > > I'm not sure why we want to make new dependency type by ALTER FUNCTION > > command, not ALTER EXTENSION? > > It's a matter of semantics. It

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

At 2016-03-21 13:04:33 +0300, a.korot...@postgrespro.ru wrote: > > I'm not sure why we want to make new dependency type by ALTER FUNCTION > command, not ALTER EXTENSION? It's a matter of semantics. It means something very different than what an 'e' dependency means. The extension doesn't own the

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

On Mon, Mar 21, 2016 at 9:34 AM, Abhijit Menon-Sen wrote: > At 2016-03-19 17:46:25 -0300, alvhe...@2ndquadrant.com wrote: > > > > I don't think the first patch is acceptable standalone -- we need both > > things together. > > OK. > > > But in reality, pg_depend handling is

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

At 2016-03-19 17:46:25 -0300, alvhe...@2ndquadrant.com wrote: > > I don't think the first patch is acceptable standalone -- we need both > things together. OK. > But in reality, pg_depend handling is mixed up with other changes all > over the place. Yes, I noticed that. :-/ > Anyway I think

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

Abhijit Menon-Sen wrote: > At 2016-01-18 11:08:19 +0530, a...@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

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

Hi Abhijit, On 3/1/16 8:36 AM, Jim Nasby wrote: On 2/29/16 10:33 PM, Abhijit Menon-Sen wrote: >Given the audience for this, I think it'd probably be OK to just >provide a function that does this, instead of DDL. That seems like a promising idea. Can you suggest some possible usage?

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

On 2/29/16 10:33 PM, Abhijit Menon-Sen wrote: >Given the audience for this, I think it'd probably be OK to just >provide a function that does this, instead of DDL. That seems like a promising idea. Can you suggest some possible usage? pg_extension_dependency( regextension, any ) where "any"

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

At 2016-02-29 19:56:07 -0600, jim.na...@bluetreble.com wrote: > > I don't see why this would be limited to just functions. […] Am I > missing something? No, you are not missing anything. The specific problem I was trying to solve involved a function, so I sketched out a solution for functions.

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

On 2/29/16 7:27 PM, Abhijit Menon-Sen wrote: 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

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

At 2016-01-18 11:08:19 +0530, a...@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

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

On 15 January 2016 at 14:26, Abhijit Menon-Sen wrote: > * «DROP EXTENSION ext» won't work without adding CASCADE, which is an > (admittedly relatively minor) inconvenience to users. > > * More importantly, pg_dump will dump all those trigger definitions, > which is

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

At 2016-01-16 12:18:53 -0500, robertmh...@gmail.com wrote: > > This seems like one manifestation of the more general problem that we > don't have any real idea what objects a function definition depends > on. Yes. I'm proposing to address a part of that problem by allowing extension dependencies

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

On Jan 16, 2016, at 9:48 AM, Abhijit Menon-Sen wrote: > Right, here's another try. > > The extension does trigger-based DML auditing. You install it using > CREATE EXTENSION and then call one of its functions to enable auditing > for a particular table. That function will

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

Right, here's another try. The extension does trigger-based DML auditing. You install it using CREATE EXTENSION and then call one of its functions to enable auditing for a particular table. That function will create a customised trigger function based on the table's columns and a trigger that

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

Abhijit Menon-Sen writes: > I'm looking at an extension that creates some triggers (on user tables) > dynamically (i.e., not during CREATE EXTENSION, but afterwards). The > author has two problems with it: > * «DROP EXTENSION ext» won't work without adding CASCADE, which

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

On Fri, Jan 15, 2016 at 7:49 AM, Tom Lane wrote: > Abhijit Menon-Sen writes: > > I'm looking at an extension that creates some triggers (on user tables) > > dynamically (i.e., not during CREATE EXTENSION, but afterwards). The > > author has two problems

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

I'm sorry, it wasn't clear from my earlier post that the triggers are dependent on a function provided by the extension. So when you do CREATE EXTENSION foo, it creates foo_somefunc() that RETURNS TRIGGER. Later, a trigger is created (somehow; in this case it is by some other function in the

[HACKERS] dealing with extension dependencies that aren't quite 'e'

Hi. I'm looking at an extension that creates some triggers (on user tables) dynamically (i.e., not during CREATE EXTENSION, but afterwards). The author has two problems with it: * «DROP EXTENSION ext» won't work without adding CASCADE, which is an (admittedly relatively minor) inconvenience to