Tom Lane writes:
> I've applied the CTAS patch after rather heavy editorialization. Don't
> know what consequences that will have for Dimitri's patch.
It allows my patch to add support for CREATE TABLE AS and SELECT INTO,
I've been doing that and am on my way to sending a v18 now. The way you
wo
On Tuesday, March 20, 2012 02:39:56 AM Tom Lane wrote:
> I've applied the CTAS patch after rather heavy editorialization. Don't
> know what consequences that will have for Dimitri's patch.
Thanks for all the work you put into this! Looks cleaner now...
Thanks,
Andres
--
Sent via pgsql-hackers
I've applied the CTAS patch after rather heavy editorialization. Don't
know what consequences that will have for Dimitri's patch.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
I wrote:
> One thing I soon found is that it lacks support for EXPLAIN SELECT INTO.
While I'm not particularly excited about fixing PREPARE ... SELECT INTO
or CREATE RULE ... SELECT INTO, I've come to the conclusion that the
EXPLAIN case is a must-fix. Because not only is EXPLAIN SELECT INTO
brok
Robert Haas writes:
> On Mon, Mar 19, 2012 at 12:53 PM, Peter Eisentraut wrote:
>> Doesn't seem worth it to me. At least, "SELECT " makes some sense:
>> rows were selected. "CREATE TABLE " means what? tables
>> were created?
>>
>> What might make sense is to delegate this ad
On Mon, Mar 19, 2012 at 12:53 PM, Peter Eisentraut wrote:
> On sön, 2012-03-18 at 21:16 -0400, Tom Lane wrote:
>> If we were going to change the output at all, I would vote for "CREATE
>> TABLE " so as to preserve the rowcount functionality. Keep in
>> mind though that this would force client
On sön, 2012-03-18 at 21:16 -0400, Tom Lane wrote:
> If we were going to change the output at all, I would vote for "CREATE
> TABLE " so as to preserve the rowcount functionality. Keep in
> mind though that this would force client-side changes, for instance in
> libpq's PQcmdTuples(). Fixing
On Mon, Mar 19, 2012 at 12:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane wrote:
>>> 1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
>>> that it can enforce that the prepared query is a SELECT. (BTW, maybe
>>> this should be wea
Robert Haas writes:
> On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane wrote:
>> 1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
>> that it can enforce that the prepared query is a SELECT. (BTW, maybe
>> this should be weakened to "something that returns tuples", in view of
>> R
On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane wrote:
> 1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
> that it can enforce that the prepared query is a SELECT. (BTW, maybe
> this should be weakened to "something that returns tuples", in view of
> RETURNING?)
+1 for "somethi
On Sunday, March 18, 2012 07:29:30 PM Tom Lane wrote:
> BTW, I've been looking through how to do what I suggested earlier to get
> rid of the coziness and code duplication between CreateTableAs and the
> prepare.c code; namely, let CreateTableAs create a DestReceiver and then
> call ExecuteQuery wi
Thom Brown writes:
> Will you also be committing the trigger function variable changes
> shortly? I don't wish to test anything prior to this as that will
> involve a complete re-test from my side anyway.
It's on its way, I had to spend time elsewhere, sorry about that. With
some luck I can post
Peter Eisentraut writes:
> On lör, 2012-03-17 at 18:04 -0400, Tom Lane wrote:
>> I'm not sure what we should do instead. We have gotten push-back before
>> anytime we changed the command tag for an existing command (and in fact
>> it seems that we intentionally added the rowcount display in 9.0,
Dimitri Fontaine writes:
> That lights a bulb: what about rewriting CREATE TABLE AS as two
> commands, internally:
Given the compatibility constraints on issues like what command tag
to return, I think that would probably make our jobs harder not easier.
regards, tom lane
On lör, 2012-03-17 at 18:04 -0400, Tom Lane wrote:
> I'm not sure what we should do instead. We have gotten push-back before
> anytime we changed the command tag for an existing command (and in fact
> it seems that we intentionally added the rowcount display in 9.0, which
> means there are people
Tom Lane writes:
> 1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
> that it can enforce that the prepared query is a SELECT. (BTW, maybe
> this should be weakened to "something that returns tuples", in view of
> RETURNING?)
That lights a bulb: what about rewriting CREATE
BTW, I've been looking through how to do what I suggested earlier to get
rid of the coziness and code duplication between CreateTableAs and the
prepare.c code; namely, let CreateTableAs create a DestReceiver and then
call ExecuteQuery with that receiver. It appears that we still need at
least two
On Saturday, March 17, 2012 11:04:30 PM Tom Lane wrote:
> I've found a couple more issues in the CTAS patch:
>
> 1. Previous versions delivered a "SELECT n" command tag for either
> spelling of the command:
>
> regression=# select * into t1 from int8_tbl;
> SELECT 6
> regression=# create table t2
I've found a couple more issues in the CTAS patch:
1. Previous versions delivered a "SELECT n" command tag for either
spelling of the command:
regression=# select * into t1 from int8_tbl;
SELECT 6
regression=# create table t2 as select * from int8_tbl;
SELECT 6
With the patch I get
regression=#
On Saturday, March 17, 2012 06:45:27 PM Tom Lane wrote:
> I'm not sure that anybody cares about being able to fire command
> triggers on DECLARE CURSOR
I actually think it would make sense to explicitly not fire command triggers
there given that DECLARE CURSOR actually potentially is somewhat perf
While looking at this I also noticed that DECLARE CURSOR uses a
structure that's randomly different in yet a third way: we start
with a utility statement containing a query, and then flip that
upside down so that the SELECT Query contains a utility statement!
I have a vague feeling that I'm the on
Andres Freund writes:
> On Friday, March 16, 2012 10:52:55 PM Tom Lane wrote:
>> Something else I just came across is that there are assorted places that
>> are aware that ExplainStmt contains a Query, eg setrefs.c, plancache.c,
>> and those have got to treat CreateTableAsStmt similarly.
> Hm. Is
On Friday, March 16, 2012 10:52:55 PM Tom Lane wrote:
> Andres Freund writes:
> > On Friday, March 16, 2012 10:31:57 PM Tom Lane wrote:
> >> I'm thinking that if the table creation
> >> were to be moved into the tuple receiver's startup routine, we could
> >> avoid needing to get control back betw
Andres Freund writes:
> On Friday, March 16, 2012 10:31:57 PM Tom Lane wrote:
>> I'm thinking that if the table creation
>> were to be moved into the tuple receiver's startup routine, we could
>> avoid needing to get control back between ExecutorStartup and
>> ExecutorRun, and then all that would
On Friday, March 16, 2012 10:31:57 PM Tom Lane wrote:
> Andres Freund writes:
> > One more thing I disliked quite a bit was the duplication of the EXECUTE
> > handling. Do you see a way to deduplicate that?
> Yeah, that's what's bugging me, too. I think a chunk of the problem is
> that you're ins
Andres Freund writes:
> One more thing I disliked quite a bit was the duplication of the EXECUTE
> handling. Do you see a way to deduplicate that?
Yeah, that's what's bugging me, too. I think a chunk of the problem is
that you're insisting on having control come back to CreateTableAs()
to perfo
On Friday, March 16, 2012 09:54:47 PM Tom Lane wrote:
> Andres Freund writes:
> > [ ctas-01.patch ]
>
> I'm starting to look at this now.
Great!
> For a patch that's supposed to de-complicate things, it seems pretty messy
:-(
Yea. It started out simple but never stopped getting more complicated
Andres Freund writes:
> [ ctas-01.patch ]
I'm starting to look at this now. For a patch that's supposed to
de-complicate things, it seems pretty messy :-(
One thing I soon found is that it lacks support for EXPLAIN SELECT INTO.
That used to work, but now you get
regression=# explain select * i
On 14 March 2012 21:33, Dimitri Fontaine wrote:
> Ok, I've implemented that. No patch attached because I need to merge
> with master again and I'm out to sleep now, it sometimes ring when being
> on-call…
>
> Curious people might have a look at my github repository where the
> command_triggers bra
Robert Haas writes:
>> Also, when calling the user's procedure from the same place in case of an
>> ANY command trigger or a specific one it's then possible to just hand
>> them over the exact same set of info (object id, name, schema name).
>
> Yes, I think that's an essential property of the sys
On Wed, Mar 14, 2012 at 4:27 AM, Dimitri Fontaine
wrote:
> Also, when calling the user's procedure from the same place in case of an
> ANY command trigger or a specific one it's then possible to just hand
> them over the exact same set of info (object id, name, schema name).
Yes, I think that's a
Robert Haas writes:
> On Tue, Mar 13, 2012 at 5:06 PM, Andres Freund wrote:
>> Generally, uppon rereading, I have to say that I am not very happy with the
>> decision that ANY triggers are fired from other places than the specific
>> triggers. That seams to be a rather dangerous/confusing route t
On Tue, Mar 13, 2012 at 5:06 PM, Andres Freund wrote:
> Generally, uppon rereading, I have to say that I am not very happy with the
> decision that ANY triggers are fired from other places than the specific
> triggers. That seams to be a rather dangerous/confusing route to me.
I agree. I think th
On Tuesday, March 13, 2012 09:07:32 PM Dimitri Fontaine wrote:
> Hi,
>
> Andres Freund writes:
> > I did a short review of what I found after merging master
>
> Thanks!
>
> > - I still find it strange not to fire on cascading actions
>
> We don't build statement for cascading so we don't fire
Hi,
Andres Freund writes:
> I did a short review of what I found after merging master
Thanks!
> - I still find it strange not to fire on cascading actions
We don't build statement for cascading so we don't fire command
triggers. The user view is that there was no drop command on the sub
object
Excerpts from Andres Freund's message of mar mar 13 08:22:26 -0300 2012:
> - I think list_command_triggers should do a heap_lock_tuple(LockTupleShared)
> on the command trigger tuple. But then again just about nothing else does :(
If you want to do something like that, I think it's probably mor
Hi,
I did a short review of what I found after merging master
(b4af1c25bbc636379efc5d2ffb9d420765705b8a) to what I currently fetched from
your repo (d63df64580114de4d83cfe8eb45eb630724b8b6f).
- I still find it strange not to fire on cascading actions
- I dislike the missing locking leading to s
On 9 March 2012 21:38, Dimitri Fontaine wrote:
> Hi,
>
> Please find attached v15 of the patch, addressing all known issues apart
> from the trigger function argument passing style. Expect a new patch
> with that taken care of early next week.
>
> (The github branch too, should you be using that)
On Fri, Mar 9, 2012 at 12:51 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> I think we had better look seriously at postponing this patch to 9.3.
>
> I understand why you're drawing that conclusion, but I don't think
> that's the best we can do here, by a long shot.
Well, if you get to the
Robert Haas writes:
> I think we had better look seriously at postponing this patch to 9.3.
I understand why you're drawing that conclusion, but I don't think
that's the best we can do here, by a long shot.
> Your reviewing is obviously moving things forward rapidly, but I think
> it's unrealist
Robert Haas writes:
> I'm not convinced. Right now, it's fairly useless - all the triggers
> could possibly do is throw an error, and an error is going to get
> thrown anyway, so it's only a question of which error message the user
> will see. But we discussed before the idea of adding a capabil
On Fri, Mar 9, 2012 at 10:05 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown wrote:
>>> Sorry, I meant any command trigger. It's because none of the commands
>>> can be run on a standby, so the triggers don't seem appropriate.
>
>> I'm not convinced. Rig
On 9 March 2012 15:05, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown wrote:
>>> Sorry, I meant any command trigger. It's because none of the commands
>>> can be run on a standby, so the triggers don't seem appropriate.
>
>> I'm not convinced. Right now, it
Robert Haas writes:
> On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown wrote:
>> Sorry, I meant any command trigger. It's because none of the commands
>> can be run on a standby, so the triggers don't seem appropriate.
> I'm not convinced. Right now, it's fairly useless - all the triggers
> could po
On 9 March 2012 14:47, Robert Haas wrote:
> On Fri, Mar 9, 2012 at 9:35 AM, Thom Brown wrote:
>> I see your point. My suggestion to Dimitri in another email was
>> either enable triggers for all commands or none. At the moment it's
>> only available on utility commands.
>
> Yeah, that's clearly
On Fri, Mar 9, 2012 at 9:35 AM, Thom Brown wrote:
> I see your point. My suggestion to Dimitri in another email was
> either enable triggers for all commands or none. At the moment it's
> only available on utility commands.
Yeah, that's clearly not the best of all possible worlds. :-)
I think
On 9 March 2012 14:30, Robert Haas wrote:
> On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown wrote:
>> On 9 March 2012 14:09, Robert Haas wrote:
>>> On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown wrote:
I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
a read-only standby, t
On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown wrote:
> On 9 March 2012 14:09, Robert Haas wrote:
>> On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown wrote:
>>> I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
>>> a read-only standby, the BEFORE ANY COMMAND trigger fires. I don't
>>>
On 9 March 2012 14:09, Robert Haas wrote:
> On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown wrote:
>> I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
>> a read-only standby, the BEFORE ANY COMMAND trigger fires. I don't
>> think any trigger should fire on a read-only standby.
>
On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown wrote:
> I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
> a read-only standby, the BEFORE ANY COMMAND trigger fires. I don't
> think any trigger should fire on a read-only standby.
Why ever not?
--
Robert Haas
EnterpriseDB: http
On 9 March 2012 00:28, Thom Brown wrote:
> On 8 March 2012 22:24, Dimitri Fontaine wrote:
>
> We're getting there. :)
It was late last night and I forgot to get around to testing pg_dump,
which isn't working correctly:
--
-- Name: cmd_trg_after_alter_aggregate; Type: COMMAND TRIGGER; Schema:
-
On 8 March 2012 22:24, Dimitri Fontaine wrote:
We're getting there. :)
> Hi,
>
> Thom Brown writes:
>> The message returned by creating a command trigger after create index
>> is still problematic:
>
> Fixed. I'm attaching an incremental patch here, the github branch is
> updated too.
Confirm
Hi,
Thom Brown writes:
> The message returned by creating a command trigger after create index
> is still problematic:
Fixed. I'm attaching an incremental patch here, the github branch is
updated too.
> CREATE VIEW doesn't return schema:
Fixed, and as an added bonus I fixed the CREATE SEQUENC
On 6 March 2012 23:25, Thom Brown wrote:
> On 6 March 2012 21:18, Thom Brown wrote:
>> On 6 March 2012 21:04, Dimitri Fontaine wrote:
> [CASCADE will not run the command triggers for cascaded objects]
If these are all expected, does it in any way compromise the
effectiveness of DDL
On 6 March 2012 21:18, Thom Brown wrote:
> On 6 March 2012 21:04, Dimitri Fontaine wrote:
[CASCADE will not run the command triggers for cascaded objects]
>>> If these are all expected, does it in any way compromise the
>>> effectiveness of DDL triggers in major use-cases?
>>
>> I don't thin
On 6 March 2012 21:04, Dimitri Fontaine wrote:
>>> [CASCADE will not run the command triggers for cascaded objects]
>> If these are all expected, does it in any way compromise the
>> effectiveness of DDL triggers in major use-cases?
>
> I don't think so. When replicating the replica will certainl
On 5 March 2012 20:42, Dimitri Fontaine wrote:
> Hi,
>
> Thanks for the extensive testing. I'm adding your tests to the
> regression suite, and keep wondering if you saw that lots of them were
> already covered? Did you try make installcheck?
Yes, but I felt it better that I come up with my own
On Sat, Mar 3, 2012 at 2:25 PM, Dimitri Fontaine wrote:
> "Kevin Grittner" writes:
>> Right. What I thought I was agreeing with was the notion that you
>> should need to specify more than the trigger name to drop the
>> trigger. Rather like how you can create a trigger AFTER INSERT OR
>> UPDATE
On Monday, March 05, 2012 09:42:00 PM Dimitri Fontaine wrote:
> > Still no command triggers firing for CREATE TABLE AS:
> Yes, Andres made CTAS a utility command, he didn't add the code that
> make them fire command triggers. I would expect his patch to get in
> first, so I don't expect him to be a
Hi,
Thanks for the extensive testing. I'm adding your tests to the
regression suite, and keep wondering if you saw that lots of them were
already covered? Did you try make installcheck?
Thom Brown writes:
> Creating a command trigger using ANY COMMAND results in oid,
> schemaname, objectname (
Tom Lane writes:
> FWIW, I agree with Thom on this. If we do it as you suggest, I
> confidently predict that it will be less than a year before we seriously
> regret it. Given all the discussion around this, it's borderline insane
> to believe that the set of parameters to be passed to command t
On 3 March 2012 19:25, Dimitri Fontaine wrote:
> "Kevin Grittner" writes:
>> Right. What I thought I was agreeing with was the notion that you
>> should need to specify more than the trigger name to drop the
>> trigger. Rather like how you can create a trigger AFTER INSERT OR
>> UPDATE OR DELET
"Kevin Grittner" writes:
> Right. What I thought I was agreeing with was the notion that you
> should need to specify more than the trigger name to drop the
> trigger. Rather like how you can create a trigger AFTER INSERT OR
> UPDATE OR DELETE, but you don't need to specify all those events to
>
Thom Brown wrote:
> Don't you mean "shouldn't need to specify more than the trigger
> name"?
You are right, that's what I meant to say.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
On 3 March 2012 16:12, Kevin Grittner wrote:
>> Thom Brown wrote:
>> Dimitri Fontaine wrote:
>>> Thom Brown writes:
problem. It was the DROP COMMAND TRIGGER statement that garnered
comment, as it makes more sense to drop the entire trigger than
individual commands for that trigge
> Thom Brown wrote:
> Dimitri Fontaine wrote:
>> Thom Brown writes:
>>> problem. It was the DROP COMMAND TRIGGER statement that garnered
>>> comment, as it makes more sense to drop the entire trigger than
>>> individual commands for that trigger.
>>
>> What you're saying here is that a single co
On 3 March 2012 14:34, Dimitri Fontaine wrote:
> Thom Brown writes:
>> problem. It was the DROP COMMAND TRIGGER statement that garnered
>> comment, as it makes more sense to drop the entire trigger than
>> individual commands for that trigger.
>
> What you're saying here is that a single command
On 3 March 2012 14:26, Dimitri Fontaine wrote:
> Thom Brown writes:
>> And having tried building it, it appears to fail.
>
> Sorry about that, my compiler here was happy building the source (and I
> had been doing make clean install along the way) and make installcheck
> passed, here.
>
> Now fix
Thom Brown writes:
> problem. It was the DROP COMMAND TRIGGER statement that garnered
> comment, as it makes more sense to drop the entire trigger than
> individual commands for that trigger.
What you're saying here is that a single command could have more than
one command attached to it, and wh
Thom Brown writes:
> And having tried building it, it appears to fail.
Sorry about that, my compiler here was happy building the source (and I
had been doing make clean install along the way) and make installcheck
passed, here.
Now fixed on my github's branch, including docs.
I'll send an updat
On 3 March 2012 13:45, Dimitri Fontaine wrote:
> Robert Haas writes:
CREATE COMMAND TRIGGER name ... properties ...;
DROP COMMAND TRIGGER name;
full stop. If you want to run the same trigger function on some
more commands, add another trigger name.
>>>
>>> +1
Robert Haas writes:
>>> CREATE COMMAND TRIGGER name ... properties ...;
>>> DROP COMMAND TRIGGER name;
>>>
>>> full stop. If you want to run the same trigger function on some
>>> more commands, add another trigger name.
>>
>> +1
>
> +1. I suggested the same thing a while back.
Yeah,
On 3 March 2012 00:08, Thom Brown wrote:
> On 2 March 2012 23:33, Thom Brown wrote:
>> On 2 March 2012 22:32, Dimitri Fontaine wrote:
> test=# CREATE TABLE badname (id int, a int, b text);
> ERROR: invalid relation name: badname
> test=# CREATE TABLE badname AS SELECT 1::int id, 1::
"anara...@anarazel.de" schrieb:
>
>
>Thom Brown schrieb:
>
>>On 2 March 2012 23:33, Thom Brown wrote:
>>> On 2 March 2012 22:32, Dimitri Fontaine
>>wrote:
>> test=# CREATE TABLE badname (id int, a int, b text);
>> ERROR: invalid relation name: badname
>> test=# CREATE TABLE badn
On Tue, Feb 28, 2012 at 10:09 AM, Kevin Grittner
wrote:
> Tom Lane wrote:
>> This seems over-complicated. Triggers on tables do not have
>> alterable properties, why should command triggers? I vote for
>>
>> CREATE COMMAND TRIGGER name ... properties ...;
>>
>> DROP COMMAND TRIGGER
On 2 March 2012 23:33, Thom Brown wrote:
> On 2 March 2012 22:32, Dimitri Fontaine wrote:
test=# CREATE TABLE badname (id int, a int, b text);
ERROR: invalid relation name: badname
test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
SELECT 1
This
On 2 March 2012 22:32, Dimitri Fontaine wrote:
> Hi,
>
> Please find attached v13 of the command trigger patch, fixing most of
> known items and rebased against master. Two important items remain to be
> done, but I figured I should keep you posted in the meantime.
Thanks Dimitri. I'll give it a
On 28 February 2012 15:03, Tom Lane wrote:
> Thom Brown writes:
>> Well the problem is that you can add commands to a trigger en masse,
>> but you can only remove them one at a time. Couldn't we at least
>> allow the removal of multiple commands at the same time? The docs you
>> wrote suggest y
Tom Lane wrote:
> This seems over-complicated. Triggers on tables do not have
> alterable properties, why should command triggers? I vote for
>
> CREATE COMMAND TRIGGER name ... properties ...;
>
> DROP COMMAND TRIGGER name;
>
> full stop. If you want to run the same trigger fu
Thom Brown writes:
> Well the problem is that you can add commands to a trigger en masse,
> but you can only remove them one at a time. Couldn't we at least
> allow the removal of multiple commands at the same time? The docs you
> wrote suggest you can do this, but you can't.
This seems over-co
On 28 February 2012 11:43, Thom Brown wrote:
> On 27 February 2012 19:37, Dimitri Fontaine wrote:
>> Thom Brown writes:
>>> CREATE COMMAND TRIGGER test_cmd_trg
>>> BEFORE CREATE SCHEMA,
>>> CREATE OPERATOR,
>>> CREATE COLLATION,
>>> CREATE CAST
>>> EXECUTE PROCEDURE my_func();
>>>
>>> I co
On 27 February 2012 19:37, Dimitri Fontaine wrote:
> Thom Brown writes:
>> CREATE COMMAND TRIGGER test_cmd_trg
>> BEFORE CREATE SCHEMA,
>> CREATE OPERATOR,
>> CREATE COLLATION,
>> CREATE CAST
>> EXECUTE PROCEDURE my_func();
>>
>> I couldn't drop it completely unless I specified all of those
Tom Lane schrieb:
>Andres Freund writes:
>> I refreshed the patch so it works again on current HEAD. Basically
>some
>> trivial fixes and dfd26f9c5f371437f243249025863ea9911aacaa. The
>latter doesn't
>> seem necessary to me after the changes, so I simply ditched it. Am I
>missing
>> somethi
Andres Freund writes:
> I refreshed the patch so it works again on current HEAD. Basically some
> trivial fixes and dfd26f9c5f371437f243249025863ea9911aacaa. The latter
> doesn't
> seem necessary to me after the changes, so I simply ditched it. Am I missing
> something?
No, that was only need
Tom Lane writes:
> FWIW, I agree with Thom on this. If we do it as you suggest, I
> confidently predict that it will be less than a year before we seriously
> regret it. Given all the discussion around this, it's borderline insane
> to believe that the set of parameters to be passed to command t
Dimitri Fontaine writes:
> Thom Brown writes:
>> I've got a question regarding the function signatures required for
>> command triggers, and apologies if it's already been discussed to
>> death (I didn't see all the original conversations around this).
>> These differ from regular trigger functio
On Monday, February 27, 2012 08:30:31 PM Thom Brown wrote:
> On 27 February 2012 19:19, Dimitri Fontaine wrote:
> > Thom Brown writes:
> >> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
> >> SELECT 1
> >>
> >> This doesn't even get picked up by ANY COMMAND.
> >
> > You
Thom Brown writes:
> CREATE COMMAND TRIGGER test_cmd_trg
> BEFORE CREATE SCHEMA,
> CREATE OPERATOR,
> CREATE COLLATION,
> CREATE CAST
> EXECUTE PROCEDURE my_func();
>
> I couldn't drop it completely unless I specified all of those commands. Why?
Because I couldn't find a nice enough way to
Thom Brown writes:
> I've got a question regarding the function signatures required for
> command triggers, and apologies if it's already been discussed to
> death (I didn't see all the original conversations around this).
> These differ from regular trigger functions which don't require any
> arg
On 27 February 2012 19:19, Dimitri Fontaine wrote:
> Thom Brown writes:
>> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
>> SELECT 1
>>
>> This doesn't even get picked up by ANY COMMAND.
>
> You won't believe it: CTAS is not implemented as a DDL. Andres did
> some work
Thom Brown writes:
> SELECT * INTO badname FROM goodname;
Again, see Andres' patch about that.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Thom Brown writes:
> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
> SELECT 1
>
> This doesn't even get picked up by ANY COMMAND.
You won't believe it: CTAS is not implemented as a DDL. Andres did
some work about that and sent a patch that received positive reviews by
b
On 26 February 2012 19:49, Thom Brown wrote:
> On 26 February 2012 14:12, Dimitri Fontaine wrote:
>> Thanks for your further testing!
>>
>> Thom Brown writes:
>>> Further testing reveals a problem with FTS configurations when using
>>> the example function provided in the docs:
>>
>> Could you s
On 26 February 2012 14:12, Dimitri Fontaine wrote:
> Thanks for your further testing!
>
> Thom Brown writes:
>> Further testing reveals a problem with FTS configurations when using
>> the example function provided in the docs:
>
> Could you send me your tests so that I add them to the proper regr
Thanks for your further testing!
Thom Brown writes:
> Further testing reveals a problem with FTS configurations when using
> the example function provided in the docs:
Could you send me your tests so that I add them to the proper regression
test? I've been lazy on one or two object types and ob
On 25 February 2012 16:36, Thom Brown wrote:
> On 25 February 2012 14:30, Thom Brown wrote:
>> On 25 February 2012 13:28, Thom Brown wrote:
>>> On 25 February 2012 13:15, Thom Brown wrote:
On 25 February 2012 12:42, Thom Brown wrote:
> On 25 February 2012 12:07, Thom Brown wrote:
>>>
On 25 February 2012 14:30, Thom Brown wrote:
> On 25 February 2012 13:28, Thom Brown wrote:
>> On 25 February 2012 13:15, Thom Brown wrote:
>>> On 25 February 2012 12:42, Thom Brown wrote:
On 25 February 2012 12:07, Thom Brown wrote:
> On 25 February 2012 12:00, Dimitri Fontaine
>>>
On 25 February 2012 13:28, Thom Brown wrote:
> On 25 February 2012 13:15, Thom Brown wrote:
>> On 25 February 2012 12:42, Thom Brown wrote:
>>> On 25 February 2012 12:07, Thom Brown wrote:
On 25 February 2012 12:00, Dimitri Fontaine wrote:
D'oh, just as I sent some more queries.
On 25 February 2012 13:15, Thom Brown wrote:
> On 25 February 2012 12:42, Thom Brown wrote:
>> On 25 February 2012 12:07, Thom Brown wrote:
>>> On 25 February 2012 12:00, Dimitri Fontaine wrote:
>>>
>>> D'oh, just as I sent some more queries...
>>>
Thom Brown writes:
> Is there any re
On 25 February 2012 12:42, Thom Brown wrote:
> On 25 February 2012 12:07, Thom Brown wrote:
>> On 25 February 2012 12:00, Dimitri Fontaine wrote:
>>
>> D'oh, just as I sent some more queries...
>>
>>> Thom Brown writes:
Is there any reason why the list of commands that command triggers can
1 - 100 of 107 matches
Mail list logo
