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
Tom Lane t...@sss.pgh.pa.us 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
Thom Brown t...@linux.com 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
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 with
On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Mar 19, 2012 at 12:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
that it can enforce that the prepared query
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 that
On Mon, Mar 19, 2012 at 12:53 PM, Peter Eisentraut pete...@gmx.net 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 19, 2012 at 12:53 PM, Peter Eisentraut pete...@gmx.net 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
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
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:
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
Tom Lane t...@sss.pgh.pa.us 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
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 out
Dimitri Fontaine dimi...@2ndquadrant.fr 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.
Peter Eisentraut pete...@gmx.net 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
Andres Freund and...@anarazel.de 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
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 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
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 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 as
Andres Freund and...@anarazel.de 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=#
On Friday, March 16, 2012 09:54:47 PM Tom Lane wrote:
Andres Freund and...@anarazel.de 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
Andres Freund and...@anarazel.de 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
On Friday, March 16, 2012 10:31:57 PM Tom Lane wrote:
Andres Freund and...@anarazel.de 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
Andres Freund and...@anarazel.de 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
On Friday, March 16, 2012 10:52:55 PM Tom Lane wrote:
Andres Freund and...@anarazel.de 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
On 14 March 2012 21:33, Dimitri Fontaine dimi...@2ndquadrant.fr 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 13, 2012 at 5:06 PM, Andres Freund and...@anarazel.de 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
On Wed, Mar 14, 2012 at 4:27 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr 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).
Robert Haas robertmh...@gmail.com 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
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
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 more
Hi,
Andres Freund and...@anarazel.de 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 Tuesday, March 13, 2012 09:07:32 PM Dimitri Fontaine wrote:
Hi,
Andres Freund and...@anarazel.de 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
On Tue, Mar 13, 2012 at 5:06 PM, Andres Freund and...@anarazel.de 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
On 9 March 2012 00:28, Thom Brown t...@linux.com wrote:
On 8 March 2012 22:24, Dimitri Fontaine dimi...@2ndquadrant.fr 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:
On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown t...@linux.com 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
On 9 March 2012 14:09, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown t...@linux.com 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
On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown t...@linux.com wrote:
On 9 March 2012 14:09, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown t...@linux.com wrote:
I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
a read-only standby, the
On 9 March 2012 14:30, Robert Haas robertmh...@gmail.com wrote:
On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown t...@linux.com wrote:
On 9 March 2012 14:09, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown t...@linux.com wrote:
I've also since found that if I
On Fri, Mar 9, 2012 at 9:35 AM, Thom Brown t...@linux.com 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.
On 9 March 2012 14:47, Robert Haas robertmh...@gmail.com wrote:
On Fri, Mar 9, 2012 at 9:35 AM, Thom Brown t...@linux.com 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
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown t...@linux.com 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
On 9 March 2012 15:05, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown t...@linux.com 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
On Fri, Mar 9, 2012 at 10:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown t...@linux.com 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
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Fri, Mar 9, 2012 at 12:51 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com 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
On 9 March 2012 21:38, Dimitri Fontaine dimi...@2ndquadrant.fr 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
Hi,
Thom Brown t...@linux.com 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
On 8 March 2012 22:24, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
We're getting there. :)
Hi,
Thom Brown t...@linux.com 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
On 6 March 2012 23:25, Thom Brown t...@linux.com wrote:
On 6 March 2012 21:18, Thom Brown t...@linux.com wrote:
On 6 March 2012 21:04, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
[CASCADE will not run the command triggers for cascaded objects]
If these are all expected, does it in any way
On 6 March 2012 21:04, Dimitri Fontaine dimi...@2ndquadrant.fr 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
On 6 March 2012 21:18, Thom Brown t...@linux.com wrote:
On 6 March 2012 21:04, Dimitri Fontaine dimi...@2ndquadrant.fr 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
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 t...@linux.com writes:
Creating a command trigger using ANY COMMAND results in oid,
schemaname,
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
On Sat, Mar 3, 2012 at 2:25 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
On 5 March 2012 20:42, Dimitri Fontaine dimi...@2ndquadrant.fr 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
Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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.
On 3 March 2012 13:45, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com 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
Thom Brown t...@linux.com 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
Thom Brown t...@linux.com 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
On 3 March 2012 14:26, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Thom Brown t...@linux.com 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
On 3 March 2012 14:34, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Thom Brown t...@linux.com 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
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 command could have
On 3 March 2012 16:12, Kevin Grittner kevin.gritt...@wicourts.gov 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
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:
Kevin Grittner kevin.gritt...@wicourts.gov 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
On 3 March 2012 19:25, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
On 2 March 2012 22:32, Dimitri Fontaine dimi...@2ndquadrant.fr 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
On 2 March 2012 23:33, Thom Brown t...@linux.com wrote:
On 2 March 2012 22:32, Dimitri Fontaine dimi...@2ndquadrant.fr 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;
On Tue, Feb 28, 2012 at 10:09 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Tom Lane t...@sss.pgh.pa.us 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
anara...@anarazel.de and...@anarazel.de schrieb:
Thom Brown t...@linux.com schrieb:
On 2 March 2012 23:33, Thom Brown t...@linux.com wrote:
On 2 March 2012 22:32, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
test=# CREATE TABLE badname (id int, a int, b text);
ERROR: invalid relation
On 3 March 2012 00:08, Thom Brown t...@linux.com wrote:
On 2 March 2012 23:33, Thom Brown t...@linux.com wrote:
On 2 March 2012 22:32, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
test=# CREATE TABLE badname (id int, a int, b text);
ERROR: invalid relation name: badname
test=# CREATE TABLE
On 27 February 2012 19:37, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Thom Brown t...@linux.com 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
On 28 February 2012 11:43, Thom Brown t...@linux.com wrote:
On 27 February 2012 19:37, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Thom Brown t...@linux.com writes:
CREATE COMMAND TRIGGER test_cmd_trg
BEFORE CREATE SCHEMA,
CREATE OPERATOR,
CREATE COLLATION,
CREATE CAST
EXECUTE
Thom Brown t...@linux.com 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
Tom Lane t...@sss.pgh.pa.us 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
On 28 February 2012 15:03, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com 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
Thom Brown t...@linux.com 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
Thom Brown t...@linux.com 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
On 27 February 2012 19:19, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Thom Brown t...@linux.com 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
Thom Brown t...@linux.com 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
Thom Brown t...@linux.com 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
On Monday, February 27, 2012 08:30:31 PM Thom Brown wrote:
On 27 February 2012 19:19, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Thom Brown t...@linux.com 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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Thom Brown t...@linux.com 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
Tom Lane t...@sss.pgh.pa.us 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
Andres Freund and...@anarazel.de 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
Tom Lane t...@sss.pgh.pa.us schrieb:
Andres Freund and...@anarazel.de 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
Thanks for your further testing!
Thom Brown t...@linux.com 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
On 26 February 2012 14:12, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Thanks for your further testing!
Thom Brown t...@linux.com 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
On 26 February 2012 19:49, Thom Brown t...@linux.com wrote:
On 26 February 2012 14:12, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Thanks for your further testing!
Thom Brown t...@linux.com writes:
Further testing reveals a problem with FTS configurations when using
the example function
On 24 February 2012 23:43, Thom Brown t...@linux.com wrote:
On 24 February 2012 23:01, Thom Brown t...@linux.com wrote:
On 24 February 2012 22:39, Thom Brown t...@linux.com wrote:
On 24 February 2012 22:32, Thom Brown t...@linux.com wrote:
On 24 February 2012 22:04, Dimitri Fontaine
On 25 February 2012 12:00, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
D'oh, just as I sent some more queries...
Thom Brown t...@linux.com writes:
Is there any reason why the list of commands that command triggers can
be used with isn't in alphabetical order? Also it appears to show
Any
On 25 February 2012 12:07, Thom Brown t...@linux.com wrote:
On 25 February 2012 12:00, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
D'oh, just as I sent some more queries...
Thom Brown t...@linux.com writes:
Is there any reason why the list of commands that command triggers can
be used
On 25 February 2012 12:42, Thom Brown t...@linux.com wrote:
On 25 February 2012 12:07, Thom Brown t...@linux.com wrote:
On 25 February 2012 12:00, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
D'oh, just as I sent some more queries...
Thom Brown t...@linux.com writes:
Is there any reason
On 25 February 2012 13:15, Thom Brown t...@linux.com wrote:
On 25 February 2012 12:42, Thom Brown t...@linux.com wrote:
On 25 February 2012 12:07, Thom Brown t...@linux.com wrote:
On 25 February 2012 12:00, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
D'oh, just as I sent some more
1 - 100 of 107 matches
Mail list logo
