On Mar 26, 2012, at 5:36 PM, Tom Lane wrote:
> Robert Haas writes:
>> 2. I'm not sure which patches Tom is planning to look at or in what
>> order, so I've been avoiding the ones he seems to be taking an
>> interest in.
>
> Well, I think I'm definitely on the hook for the pg_stat_statements,
> p
Robert Haas writes:
> 2. I'm not sure which patches Tom is planning to look at or in what
> order, so I've been avoiding the ones he seems to be taking an
> interest in.
Well, I think I'm definitely on the hook for the pg_stat_statements,
pgsql_fdw, foreign table stats, and caching-stable-subexpr
On Mon, Mar 26, 2012 at 4:45 PM, Robert Haas wrote:
> As soon as we're done here, the CommitFest will end, and there won't
> be any other people's patches to review.
Hurray? :-)
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle
On Mon, Mar 26, 2012 at 4:36 PM, Dimitri Fontaine
wrote:
> Well, wait a minute. There's a difference between half-baked and
> reacting to a review that changes the goal of a patch. My idea of the
> code I wanted to write here is extremely different from what we as a
> community decided to be doing
On 26 March 2012 21:36, Dimitri Fontaine wrote:
> Robert Haas writes:
>> Personally, I am about at the point where I'd like to punt everything
>> and move on. As nice as it would be to squeeze a few more things into
>> 9.2, there WILL be a 9.3. If a few less people had submitted
>> half-baked c
Robert Haas writes:
> 1. It sure seems like there is an awful lot of code churn and design
> work going on.
There has only been minor adjustments for a while now, and they have
been visible because Thom was doing lots of testing for me and it was
way easier for me to publish a new version and hav
On Monday, March 26, 2012 10:18:59 PM Dimitri Fontaine wrote:
> don't know how to fix the plpython specifics he's talking
> about.
Just copy what is done in the normal trigger handling facility (the decref
both in the CATCH and in the normal path). Ping me some other way if you need
help...
And
Tom Lane writes:
> So I don't think that the mere fact of being an ANY trigger rather than
> a command-specific trigger should be taken to mean that a particular
> ordering is desirable. Trigger name order isn't the greatest solution
> by any means, but it's more flexible than hard-wiring accordi
On Mon, Mar 26, 2012 at 3:36 PM, Thom Brown wrote:
> Can someone clarify whether this will be reviewed by a committer?
> Will there be time to get this reviewed before the commitfest closes?
> I get the impression the commitfest closure is fairly imminent.
Well, I have been holding off for two re
Thom Brown writes:
> Can someone clarify whether this will be reviewed by a committer?
> Will there be time to get this reviewed before the commitfest closes?
> I get the impression the commitfest closure is fairly imminent.
I don't have that impression. (I wish I did.)
Dimitri Fontaine writes:
> Robert Haas writes:
>> Dimitri's proposed behavior would be advantageous if you have an ANY
>> trigger that wants to "take over the world" and make sure that nobody
>> else can run before it. I think, though, that's not a case we want to
>> cater to - all of this stuff
On Mon, Mar 26, 2012 at 3:24 PM, Dimitri Fontaine
wrote:
> One use case would be for londiste/slony/bucardo to rewrite the command
> and queue its text, that will be done in C and should probably be done
> first. Using an ANY command trigger means that code will run before user
> specific code (or
Can someone clarify whether this will be reviewed by a committer?
Will there be time to get this reviewed before the commitfest closes?
I get the impression the commitfest closure is fairly imminent.
Thom
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
Robert Haas writes:
> Dimitri's proposed behavior would be advantageous if you have an ANY
> trigger that wants to "take over the world" and make sure that nobody
> else can run before it. I think, though, that's not a case we want to
> cater to - all of this stuff requires superuser privileges a
On Sun, Mar 25, 2012 at 12:15 PM, Andres Freund wrote:
> On Friday, March 16, 2012 10:40:46 AM Dimitri Fontaine wrote:
>> > This will have the effect of calling triggers outside of alphabetic
>> > order. I don't think thats a good idea even if one part is ANY and the
>> > other a specific command.
On Friday, March 16, 2012 10:40:46 AM Dimitri Fontaine wrote:
> > This will have the effect of calling triggers outside of alphabetic
> > order. I don't think thats a good idea even if one part is ANY and the
> > other a specific command.
> > I don't think there is any reason anymore to separate th
On 16 March 2012 16:26, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane writes:
>>> If you think "cmdtrigger" isn't a good name maybe you should have
>>> picked a different one to start with.
>
>> Well, I think it's a good internal name. I'm not too sure about exposing
>> it, the only rea
Dimitri Fontaine writes:
> Tom Lane writes:
>> If you think "cmdtrigger" isn't a good name maybe you should have
>> picked a different one to start with.
> Well, I think it's a good internal name. I'm not too sure about exposing
> it, the only reason why it's a good name is because it's a single
Robert Haas writes:
> there has to be some way to do that without breaking command triggers.
Sure, special case the switch branch in utility.c so as to return a
different command tag for ALTER TABLE and ALTER FOREIGN TABLE. For
precedents, see AlterObjectTypeCommandTag(ObjectType objtype) and
On Fri, Mar 16, 2012 at 7:42 AM, Dimitri Fontaine
wrote:
>> I don’t know if this was a problem before that I didn’t spot
>> (probably), but triggers for both ANY COMMAND and ALTER FOREIGN TABLE
>> show a command tag of ALTER TABLE for ALTER FOREIGN TABLE statements
>> where the column is renamed:
Tom Lane writes:
> Multi-word type names are a serious pain in the ass; they require
> hackery in a lot of places. We support the ones that the SQL spec
> requires us to, but I will object in the strongest terms to inventing
> any that are not required by spec. I object in even stronger terms to
Andres Freund writes:
> On Friday, March 16, 2012 02:50:55 PM Tom Lane wrote:
>> While I'm looking at the grammar ... it also seems like a serious
>> PITA from a maintenance standpoint that we're now going to have to
>> adjust the CREATE COMMAND TRIGGER productions every time somebody
>> thinks of
On Friday, March 16, 2012 02:50:55 PM Tom Lane wrote:
> While I'm looking at the grammar ... it also seems like a serious
> PITA from a maintenance standpoint that we're now going to have to
> adjust the CREATE COMMAND TRIGGER productions every time somebody
> thinks of a new SQL command.
I don't
Andres Freund writes:
> On Thursday, March 15, 2012 10:58:49 PM Dimitri Fontaine wrote:
>> I tricked that in the grammar, the type is called cmdtrigger but I
>> though it wouldn't be a good choice for the SQL statement.
> Hm. I am decidedly unhappy with that grammar hackery... But then maybe I am
On 16 March 2012 12:07, Dimitri Fontaine wrote:
> Thom Brown writes:
>> Okay, I shalln't do any more testing until the next patch. I should
>> probably have worked on automating my tests more, but never got round
>> to it.
>
> make installcheck :)
>
> That said, your test allow to spot OID prob
Thom Brown writes:
> Okay, I shalln't do any more testing until the next patch. I should
> probably have worked on automating my tests more, but never got round
> to it.
make installcheck :)
That said, your test allow to spot OID problems that we can't add in the
regression tests (OID being t
On 16 March 2012 11:42, Dimitri Fontaine wrote:
> Thom Brown writes:
>> Specific command triggers on ALTER VIEW don’t work at all:
>
> Can't reproduce, and that's already part of the regression tests.
This was a problem my side (a mistake I made previously) as I hadn't
added this particular one
Thom Brown writes:
> Note: incremental patch attached for the following section...
Applied, thanks!
> I don’t know if this was a problem before that I didn’t spot
> (probably), but triggers for both ANY COMMAND and ALTER FOREIGN TABLE
> show a command tag of ALTER TABLE for ALTER FOREIGN TABLE s
Andres Freund writes:
> On Thursday, March 15, 2012 10:58:49 PM Dimitri Fontaine wrote:
>> I tricked that in the grammar, the type is called cmdtrigger but I
>> though it wouldn't be a good choice for the SQL statement.
> Hm. I am decidedly unhappy with that grammar hackery... But then maybe I am
On Friday, March 16, 2012 09:55:10 AM Thom Brown wrote:
> On 16 March 2012 08:45, Andres Freund wrote:
> > On Friday, March 16, 2012 09:30:58 AM Thom Brown wrote:
> >> On 16 March 2012 08:13, Andres Freund wrote:
> >> > On Thursday, March 15, 2012 11:41:21 PM Thom Brown wrote:
> >> >> Looks like
On 16 March 2012 08:45, Andres Freund wrote:
> On Friday, March 16, 2012 09:30:58 AM Thom Brown wrote:
>> On 16 March 2012 08:13, Andres Freund wrote:
>> > On Thursday, March 15, 2012 11:41:21 PM Thom Brown wrote:
>> >> Looks like the ctas-on-command-triggers-01.patch patch needs re-basing.
>> >
On 15 March 2012 21:58, Dimitri Fontaine wrote:
> Thom Brown writes:
>> I don’t understand how functions can return a type of “command
>> trigger”. This certainly works, but I’ve never seen a type consisting
>> of more than one word. Could you explain this for me? This is also
>
> I tricked th
On Friday, March 16, 2012 09:30:58 AM Thom Brown wrote:
> On 16 March 2012 08:13, Andres Freund wrote:
> > On Thursday, March 15, 2012 11:41:21 PM Thom Brown wrote:
> >> Looks like the ctas-on-command-triggers-01.patch patch needs re-basing.
> >
> > I can do that - but imo the other patch (not ba
Hi,
On Thursday, March 15, 2012 10:58:49 PM Dimitri Fontaine wrote:
> I tricked that in the grammar, the type is called cmdtrigger but I
> though it wouldn't be a good choice for the SQL statement.
Hm. I am decidedly unhappy with that grammar hackery... But then maybe I am
squeamish.
> + oid |
On 16 March 2012 08:13, Andres Freund wrote:
> On Thursday, March 15, 2012 11:41:21 PM Thom Brown wrote:
>> Looks like the ctas-on-command-triggers-01.patch patch needs re-basing.
> I can do that - but imo the other patch (not based on the command triggers
> stuff) is the relevant for now as this
* Thom Brown wrote:
I don’t understand how functions can return a type of “command
trigger”. This certainly works, but I’ve never seen a type consisting
of more than one word. Could you explain this for me? This is also
postgres=> with types (name) as
postgres-> (select format_type(oid, NUL
On Thursday, March 15, 2012 11:41:21 PM Thom Brown wrote:
> On 15 March 2012 22:06, Dimitri Fontaine wrote:
> > Dimitri Fontaine writes:
> >>> At this moment in time, CTAS is still outstanding. Is the plan to try
> >>> to get that in for this release, or as an enhancement in 9.3?
> >>
> >> The
On 15 March 2012 22:06, Dimitri Fontaine wrote:
> Dimitri Fontaine writes:
>>> At this moment in time, CTAS is still outstanding. Is the plan to try
>>> to get that in for this release, or as an enhancement in 9.3?
>>
>> The plan is to get CTAS as a utility command in 9.2 then update the
>> comm
Dimitri Fontaine writes:
>> At this moment in time, CTAS is still outstanding. Is the plan to try
>> to get that in for this release, or as an enhancement in 9.3?
>
> The plan is to get CTAS as a utility command in 9.2 then update the
> command trigger patch to benefit from the new situation. We'
Thanks for testing this new version (again).
A quick answer now, I'll send another patch tomorrow.
Thom Brown writes:
> I don’t understand how functions can return a type of “command
> trigger”. This certainly works, but I’ve never seen a type consisting
> of more than one word. Could you expl
On 15 March 2012 18:13, Dimitri Fontaine wrote:
> Hi,
>
> I guess it's time to start a new thread here. Please find attached
> version 16 of the command trigger patch, with augmented documentation
> and “magic variable” support (TG_WHEN, TG_OBJECTID and such).
>
> The current version of the patch
41 matches
Mail list logo
