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:
http://www.postgresql.org
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
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 s
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: =?UTF-8?q?Implement=20"ALTER=20
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. There's
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 tha
Á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 pg
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
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 toda
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 could
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 could
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
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 wh
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:
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 alternativ
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 2920
> >
> > 1181 Alter
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 AlterObjectDependsStmt: ALTER TRIGGER name
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 cas
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 (pgsql-hackers@postgre
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 something very different
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 agr
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
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 means something very diffe
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 f
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 mixed up with other cha
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 thi
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 itself
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?
pg_extens
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" w
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.
Onc
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 extens
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 t
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 inappropriate in this case
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
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 create a customised trig
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 uses
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 exten
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 with it:
>
>
How do these triggers come to
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 is an
> (admittedly r
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
40 matches
Mail list logo