On Mon, Jan 28, 2013 at 6:19 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Christopher Browne cbbro...@gmail.com writes:
I'm poking at event triggers a bit; would like to set up some examples
(and see if they
work, or break down badly; both are interesting results) to do some
validation
Christopher Browne cbbro...@gmail.com writes:
Hmm. I think some information about the object is pretty needful.
For the immediate case I'm poking at, namely looking for dropped tables,I
could determine that which object is gone by inference; if I run the trigger
as part of the
I'm poking at event triggers a bit; would like to set up some examples
(and see if they
work, or break down badly; both are interesting results) to do some
validation of schema
for Slony.
What I'm basically thinking about is to set up some event triggers that run on
DROP TABLE / DROP SEQUENCE,
Christopher Browne cbbro...@gmail.com writes:
I'm poking at event triggers a bit; would like to set up some examples
(and see if they
work, or break down badly; both are interesting results) to do some
validation of schema
for Slony.
Cool, thanks!
What I'm basically thinking about is to
On 13-01-26 11:11 PM, Robert Haas wrote:
On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
My understanding is that if the command string we give to event triggers
is ambiguous (sub-object names, schema qualifications, etc), it comes
useless for logical
On Sun, Jan 27, 2013 at 12:08 PM, Steve Singer ssin...@ca.afilias.info wrote:
On 13-01-26 11:11 PM, Robert Haas wrote:
On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
My understanding is that if the command string we give to event triggers
is ambiguous
Robert Haas robertmh...@gmail.com writes:
The current patch implementation is to fill in the object id, name and
schema with NULL when we have something else than a single object as the
target. I did that when I realized we have a precedent with statement
triggers and that we would maybe share
On Sun, Jan 27, 2013 at 12:57 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
The current patch implementation is to fill in the object id, name and
schema with NULL when we have something else than a single object as the
target. I did that when I
Robert Haas robertmh...@gmail.com writes:
Well I would think that we don't support droping several objects at
once yet in 9.3 is an acceptable answer.
On that point, I disagree.
Ok, will provide a patch for that soon, then. I did give higher priority
to exposing more information, ok to
On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
My understanding is that if the command string we give to event triggers
is ambiguous (sub-object names, schema qualifications, etc), it comes
useless for logical replication use. I'll leave it to the consumers of
[ changing subject line to keep threads of discussion separate ]
On Thu, Jan 24, 2013 at 5:51 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Something like this part:
+ -- now try something crazy to ensure we don't crash the backend
+ create function test_event_trigger_drop_function()
+
On Thu, Jan 24, 2013 at 5:43 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
But I wonder: wouldn't it be better to just expose the raw string the
user typed? I mean, in all the cases we really care about, the
information we can *reliably* expose at this point is going to be
pretty nearly
Robert Haas robertmh...@gmail.com writes:
OK, but can we lay the issue of a *normalized* command string to the
side for just one minute, and talk about exposing the *raw* command
string? It seems to me that this would be (1) very easy to do, (2)
reasonable to slip into 9.3, and (3) useful to
On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
OK, but can we lay the issue of a *normalized* command string to the
side for just one minute, and talk about exposing the *raw* command
string? It seems to me that this
Robert Haas robertmh...@gmail.com writes:
Or maybe we should just silently ignore failures to look up the event
trigger. That might be better, because the DBA could always do:
DROP FUNCTION myeventtrgfn() CASCADE;
...and it would be undesirable for other sessions to error out in that
case
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 21, 2013 at 12:27 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
- Context exposing and filtering
I'm not feeling very sanguine about any of this. I feel strongly that
we should try to do something that's more principled than just
Robert Haas robertmh...@gmail.com writes:
Can you point me specifically at what you have in mind so I can make
sure I'm considering the right thing?
Something like this part:
+ -- now try something crazy to ensure we don't crash the backend
+ create function test_event_trigger_drop_function()
On 13-01-24 05:43 AM, Dimitri Fontaine wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 21, 2013 at 12:27 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
- Context exposing and filtering
I'm not feeling very sanguine about any of this. I feel strongly that
we should try to
Robert Haas robertmh...@gmail.com writes:
I think these new regression tests are no good, because I doubt that
the number of recursive calls that can fit into any given amount of
stack space is guaranteed to be the same on all platforms. I have
committed the bug fixes themselves, however.
On Wed, Jan 23, 2013 at 4:57 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Thanks for commiting the fixes. About the regression tests, I think
you're right, but then I can't see how to include such a test. Maybe you
could add the other one, though?
Can you point me specifically at what
On Wed, Jan 23, 2013 at 09:33:58AM -0500, Robert Haas wrote:
On Wed, Jan 23, 2013 at 4:57 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Thanks for commiting the fixes. About the regression tests, I think
you're right, but then I can't see how to include such a test. Maybe you
could
On Wed, Jan 23, 2013 at 2:36 PM, Bruce Momjian br...@momjian.us wrote:
On Wed, Jan 23, 2013 at 09:33:58AM -0500, Robert Haas wrote:
On Wed, Jan 23, 2013 at 4:57 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Thanks for commiting the fixes. About the regression tests, I think
you're
On Wed, Jan 23, 2013 at 03:02:24PM -0500, Robert Haas wrote:
On Wed, Jan 23, 2013 at 2:36 PM, Bruce Momjian br...@momjian.us wrote:
On Wed, Jan 23, 2013 at 09:33:58AM -0500, Robert Haas wrote:
On Wed, Jan 23, 2013 at 4:57 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Thanks for
Robert Haas robertmh...@gmail.com writes:
Nice clean patch, thanks!
Committed, after tinkering with the CommandCounterIncrement() stuff a bit.
Cool. thanks!
I will respond to the rest of your email later. Reading through this
patch left me with a slight concern regarding both
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
I added some in the attached patch.
doc/src/sgml/event-trigger.sgml | 10 ++
src/backend/commands/event_trigger.c|6 +-
src/test/regress/expected/event_trigger.out | 106 +++
On 22 January 2013 12:02, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Dickson S. Guedes lis...@guedesoft.net writes:
2013/1/21 Robert Haas robertmh...@gmail.com:
Another thing is that we might want to document that if a command
errors out, ddl_command_end will never be reached; and
Thom Brown t...@linux.com writes:
Would it be desirable to have ddl_command_success and
ddl_command_failed events. These would effectively be subsets to
No, because you can't run any SQL in a failed transaction.
This, unfortunately, introducing awkwardness with the WHEN clause
restriction
On 22 January 2013 13:28, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Thom Brown t...@linux.com writes:
Would it be desirable to have ddl_command_success and
ddl_command_failed events. These would effectively be subsets to
No, because you can't run any SQL in a failed transaction.
Okay,
Thom Brown t...@linux.com writes:
Ah, in that case, the docs are wrong:
http://www.postgresql.org/docs/devel/static/sql-createeventtrigger.html
Oh. It's missing the comma and applying the AND at the wrong level,
here's a fix:
diff --git a/doc/src/sgml/ref/create_event_trigger.sgml
On 22 January 2013 14:45, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Thom Brown t...@linux.com writes:
Ah, in that case, the docs are wrong:
http://www.postgresql.org/docs/devel/static/sql-createeventtrigger.html
Oh. It's missing the comma and applying the AND at the wrong level,
here's
On 22 January 2013 14:47, Thom Brown t...@linux.com wrote:
On 22 January 2013 14:45, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Thom Brown t...@linux.com writes:
Ah, in that case, the docs are wrong:
http://www.postgresql.org/docs/devel/static/sql-createeventtrigger.html
Oh. It's missing
On 22 January 2013 16:28, Thom Brown t...@linux.com wrote:
On 22 January 2013 14:47, Thom Brown t...@linux.com wrote:
postgres=# CREATE EVENT TRIGGER cmd_trg_after_any_command ON
ddl_command_end WHEN TAG IN ('ANY COMMAND') EXECUTE PROCEDURE
cmd_trg_info();
CREATE EVENT TRIGGER
I can see why
Thom Brown t...@linux.com writes:
ALTER INDEX is missing from the event trigger matrix.
When renaming a column on a foreign table, tg_tag reports 'ALTER
TABLE' instead of 'ALTER FOREIGN TABLE'. It doesn't do this for any
other ALTER FOREIGN TABLE operation, including altering, adding or
Thom Brown t...@linux.com writes:
test2=# CREATE EVENT TRIGGER cmd_trg_before_any_command ON
ddl_command_end WHEN TAG IN ('MEOW LIKE A CAT') EXECUTE PROCEDURE
cmd_trg_info_any();
CREATE EVENT TRIGGER
...unless I've coincidentally stumbled upon the new MEOW LIKE A CAT
command coming in 9.3.
On 2013-01-18 17:20:51 -0500, Robert Haas wrote:
On Fri, Jan 18, 2013 at 5:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, that burden already exists for non-utility statements ---
On Tue, Jan 22, 2013 at 7:29 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
I added some in the attached patch.
doc/src/sgml/event-trigger.sgml | 10 ++
src/backend/commands/event_trigger.c|6 +-
On Tue, Jan 22, 2013 at 7:02 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
I had to make quiet a part of the regression tests because of the ERROR
message containing an OID, where I think it's the right error message.
I have a feeling that's the sort of error message that we don't want
On Tue, Jan 22, 2013 at 11:38 AM, Thom Brown t...@linux.com wrote:
...unless I've coincidentally stumbled upon the new MEOW LIKE A CAT
command coming in 9.3. ;)
+1 for adding that. I've been wanting it for years.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
On 23/01/13 16:02, Robert Haas wrote:
On Tue, Jan 22, 2013 at 11:38 AM, Thom Brown t...@linux.com wrote:
...unless I've coincidentally stumbled upon the new MEOW LIKE A CAT
command coming in 9.3. ;)
+1 for adding that. I've been wanting it for years.
Can we have it back ported to 9.2,
On Wed, Jan 23, 2013 at 12:23 PM, Gavin Flower
gavinflo...@archidevsys.co.nz wrote:
On 23/01/13 16:02, Robert Haas wrote:
On Tue, Jan 22, 2013 at 11:38 AM, Thom Brown t...@linux.com
t...@linux.com wrote:
...unless I've coincidentally stumbled upon the new MEOW LIKE A CAT
command coming
On Mon, Jan 21, 2013 at 12:27 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
- Context exposing and filtering
My preference for that point is to include it and limit it to event
triggers written in C, leaving the door open to add new events in
the future, and allowing
Robert Haas robertmh...@gmail.com writes:
Ok. Will prepare a non controversial patch for ddl_command_end.
Thanks. I will make a forceful effort to review that in a timely
fashion when it's posted.
Please find it attached to this email.
COLUMNS=72 git diff --stat
On Mon, Jan 21, 2013 at 12:27 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Please find it attached to this email.
Nice clean patch, thanks!
Committed, after tinkering with the CommandCounterIncrement() stuff a bit.
I will respond to the rest of your email later. Reading through this
2013/1/21 Robert Haas robertmh...@gmail.com:
Another thing is that we might want to document that if a command
errors out, ddl_command_end will never be reached; and perhaps also
that if ddl_command_start errors out, the command itself will never be
reached. Perhaps this is so obvious as to
Tom Lane t...@sss.pgh.pa.us writes:
Robert Haas robertmh...@gmail.com writes:
I'm somewhat bemused by this comment. I don't think
CommandCounterIncrement() is an article of faith. If you execute a
command to completion, and do a CommandCounterIncrement(), then
whatever you do next will look
On 2013-01-17 22:39:18 -0500, Robert Haas wrote:
On Thu, Jan 17, 2013 at 8:33 PM, Andres Freund and...@2ndquadrant.com wrote:
I have no problem requiring C code to use the even data, be it via hooks
or via C functions called from event triggers. The problem I have with
putting in some hooks
On Fri, Jan 18, 2013 at 9:07 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-01-17 22:39:18 -0500, Robert Haas wrote:
On Thu, Jan 17, 2013 at 8:33 PM, Andres Freund and...@2ndquadrant.com
wrote:
I have no problem requiring C code to use the even data, be it via hooks
or via C
On 18 January 2013 02:48, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
I have no problem requiring C code to use the even data, be it via hooks
or via C functions called from event triggers. The problem I have with
putting in some hooks is that I doubt that
On 2013-01-18 09:58:53 -0500, Robert Haas wrote:
On Fri, Jan 18, 2013 at 9:07 AM, Andres Freund and...@2ndquadrant.com wrote:
I don't have a problem reusing the object access infrastructure at all. I
just
don't think its providing even remotely enough. You have (co-)written that
stuff,
On Fri, Jan 18, 2013 at 10:47 AM, Andres Freund and...@2ndquadrant.com wrote:
No, there's one also in heap_create_with_catalog. Took me a minute to
find it, as it does not use InvokeObjectAccessHook. The idea is that
OAT_POST_CREATE fires once per object creation, regardless of the
object
On 2013-01-18 11:42:47 -0500, Robert Haas wrote:
On Fri, Jan 18, 2013 at 10:47 AM, Andres Freund and...@2ndquadrant.com
wrote:
No, there's one also in heap_create_with_catalog. Took me a minute to
find it, as it does not use InvokeObjectAccessHook. The idea is that
OAT_POST_CREATE fires
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-18 11:42:47 -0500, Robert Haas wrote:
I'm having trouble following this. Can you restate? I wasn't sure
what you meant by libpqdump. I assumed you were speaking of a
parsetree-DDL or catalog-DDL facility.
Yea, that wasn't really
On 2013-01-18 12:44:13 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-18 11:42:47 -0500, Robert Haas wrote:
I'm having trouble following this. Can you restate? I wasn't sure
what you meant by libpqdump. I assumed you were speaking of a
parsetree-DDL or
Andres Freund escribió:
On 2013-01-18 12:44:13 -0500, Tom Lane wrote:
An issue that would have to be thought about is that there are assorted
scenarios where we generate parse trees that contain options that
cannot be generated from SQL, so there's no way to reverse-list them
into
On 2013-01-18 15:22:55 -0300, Alvaro Herrera wrote:
Andres Freund escribió:
On 2013-01-18 12:44:13 -0500, Tom Lane wrote:
An issue that would have to be thought about is that there are assorted
scenarios where we generate parse trees that contain options that
cannot be generated from
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Andres Freund escribió:
Dimitri's earlier patches had support for quite some commands via
deparsing and while its a noticeable amount of code it seemed to work
ok.
The last revision I could dig out is
On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Andres Freund escribió:
Dimitri's earlier patches had support for quite some commands via
deparsing and while its a noticeable amount of code it seemed to work
ok.
The last
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, that burden already exists for non-utility statements --- why
should utility statements get a pass? Other than that we tend to invent
new utility syntax freely, which might be a
On Fri, Jan 18, 2013 at 5:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, that burden already exists for non-utility statements --- why
should utility statements get a pass? Other
Robert Haas robertmh...@gmail.com writes:
- adds ddl_command_trace and ddl_command_end events
- causes those events to be called not only for actual SQL commands
but also for things that happen, at present, to go through the same
code path
- adds additional magic variables to PL/pgsql to
On Thu, Jan 17, 2013 at 5:18 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Now, if that's what it takes, I'll spend time on it. In which exact
order do you want to be reviewing and applying that series of patches?
Let's agree on which things we even want to do first. Here's my take:
-
On 2013-01-17 11:15:24 -0500, Robert Haas wrote:
As a further example, suppose that in 9.4 (or 9.17) we add a command
DROP TABLES IN SCHEMA fred WHERE name LIKE 'bob%'. Well, the
logging trigger still just works (because it's only writing the
statement, without caring about its contents).
Robert Haas robertmh...@gmail.com writes:
- adds ddl_command_trace and ddl_command_end events
I think ddl_command_end is OK and I'm willing to commit that if
extracted as its own patch. I think ddl_command_trace is unnecessary
syntactic sugar.
Ok. Will prepare a non controversial patch for
On 17 January 2013 16:15, Robert Haas robertmh...@gmail.com wrote:
As a further example, suppose that in 9.4 (or 9.17) we add a command
DROP TABLES IN SCHEMA fred WHERE name LIKE 'bob%'. Well, the
logging trigger still just works (because it's only writing the
statement, without caring about
Simon Riggs si...@2ndquadrant.com writes:
On 17 January 2013 16:15, Robert Haas robertmh...@gmail.com wrote:
It pains me that I've evidently failed to communicate this concept
clearly despite a year or more of trying. Does that make sense? Is
there some way I can make this more clear? The
On Thu, Jan 17, 2013 at 12:06 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Ok. Will prepare a non controversial patch for ddl_command_end.
Thanks. I will make a forceful effort to review that in a timely
fashion when it's posted.
I think this is a bad idea, not only because, as I said
Robert Haas robertmh...@gmail.com writes:
Goal: Every time an ALTER command is used on object *that actually
exists*, we will call some user-defined function and pass the object
type, the OID of the object, and some details about what sort of
alteration the user has requested.
Ok, in current
Tom Lane t...@sss.pgh.pa.us writes:
I have to completely disagree with that. If we don't want PostgreSQL
to soon subside into an unfixable morass, as I think Brooks puts it,
we must *not* simply patch things in a way that expediently provides
an approximation of some desired feature. We have
On 17 January 2013 20:24, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 17 January 2013 16:15, Robert Haas robertmh...@gmail.com wrote:
It pains me that I've evidently failed to communicate this concept
clearly despite a year or more of trying. Does that make
Robert Haas robertmh...@gmail.com writes:
Let me try to give a concrete example of how I think another firing
point could be made to work along the lines I'm suggesting.
[ snip description of how an event trigger might safely be fired just
after identification and locking of the target object
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
I think that we're not realistically going to be able to introduce
event triggers in very many of the places we'd like to have them
without first doing a lot of fundamental refactoring.
We're only talking
Simon Riggs si...@2ndquadrant.com writes:
On 17 January 2013 20:24, Tom Lane t...@sss.pgh.pa.us wrote:
My comments were in response to this
I don't really agree with that. I think the point is to expose what
the system is doing to the DBA. I'm OK with exposing the fact that
creating a
Tom Lane t...@sss.pgh.pa.us writes:
Well, that's already a problem, because as Robert keeps saying, what
goes through utility.c and what doesn't is pretty random right at the
moment, and we shouldn't expose that behavior to users for fear of not
being able to change it later.
It didn't feel
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Well, that's already a problem, because as Robert keeps saying, what
goes through utility.c and what doesn't is pretty random right at the
moment, and we shouldn't expose that behavior to users for fear of not
On Thu, Jan 17, 2013 at 4:43 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
Goal: Every time an ALTER command is used on object *that actually
exists*, we will call some user-defined function and pass the object
type, the OID of the object, and
On Thu, Jan 17, 2013 at 5:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Perhaps it would improve matters if we refactored DDL processing so that
there were separate parse analysis and execution phases, where parse
analysis is (perhaps among other responsibilities) responsible for
identifying and
On 2013-01-17 23:48:23 +0100, Dimitri Fontaine wrote:
Tom Lane t...@sss.pgh.pa.us writes:
Alternatively, if you want to get something into 9.3 that has not
necessarily got a long-term-stable API, I'd be inclined to suggest that
we forget about a SQL-level event trigger facility for now, and
On 01/18/2013 04:24 AM, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 17 January 2013 16:15, Robert Haas robertmh...@gmail.com wrote:
It pains me that I've evidently failed to communicate this concept
clearly despite a year or more of trying. Does that make sense? Is
there
On 01/18/2013 09:33 AM, Andres Freund wrote:
I have no problem requiring C code to use the even data, be it via
hooks or via C functions called from event triggers. The problem I
have with putting in some hooks is that I doubt that you can find
sensible spots with enough information to
On 2013-01-18 10:31:28 +0800, Craig Ringer wrote:
On 01/18/2013 09:33 AM, Andres Freund wrote:
I have no problem requiring C code to use the even data, be it via
hooks or via C functions called from event triggers. The problem I
have with putting in some hooks is that I doubt that you can
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 17, 2013 at 4:43 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
because that
sounded logical if you believe in CommandCounterIncrement.
I'm somewhat bemused by this comment. I don't think
CommandCounterIncrement() is an article of
On 01/18/2013 10:34 AM, Andres Freund wrote:
On 2013-01-18 10:31:28 +0800, Craig Ringer wrote:
On 01/18/2013 09:33 AM, Andres Freund wrote:
I have no problem requiring C code to use the even data, be it via
hooks or via C functions called from event triggers. The problem I
have with putting
Andres Freund and...@2ndquadrant.com writes:
I have no problem requiring C code to use the even data, be it via hooks
or via C functions called from event triggers. The problem I have with
putting in some hooks is that I doubt that you can find sensible spots
with enough information to
On 2013-01-17 21:48:01 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I have no problem requiring C code to use the even data, be it via hooks
or via C functions called from event triggers. The problem I have with
putting in some hooks is that I doubt that you can find
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-17 21:48:01 -0500, Tom Lane wrote:
If we're only interested in replication, let's put in some hooks whose
contract does not allow for side-effects on the local catalogs, and be
done. Otherwise we'll be putting in man-years of unnecessary
On Thu, Jan 17, 2013 at 8:33 PM, Andres Freund and...@2ndquadrant.com wrote:
I have no problem requiring C code to use the even data, be it via hooks
or via C functions called from event triggers. The problem I have with
putting in some hooks is that I doubt that you can find sensible spots
On Wed, Jan 9, 2013 at 11:58 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I made some changes to this, and I think the result (attached) is
cleaner overall.
Now, this review is pretty much unfinished as far as I am concerned;
mainly I've been trying to figure out how it all works and
Robert Haas robertmh...@gmail.com writes:
I think this points to a couple of problems: this patch isn't
well-enough thought out, and it's got several features jammed into a
single patch. This should really be split up into several patches and
each one submitted separately.
Ok. Now I want to
On Wed, Jan 16, 2013 at 4:16 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Ok. Now I want to talk about our process a little. That's a 2 paragraphs
diversion, after that it's getting back to technical matters.
There's a difference between it's not the way I would have done it and
the
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
There's a difference between it's not the way I would have done it and
the author didn't think about what he's doing. That's also the reason
why it's very hard to justify sending a polished enough patch as a non
commiter.
And then this patch is
On Wed, Jan 16, 2013 at 6:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What was discussed at the last dev meeting was assigning a committer to
each large patch to start with, which would reduce the risk of the
goalposts moving that way. It seems to me that Robert's at least
unofficially taken
Dimitri Fontaine escribió:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Given the OID, we use the ObjectProperty[] structure to know which cache
or catalog to scan in order to get the name and namespace of the object.
The changes to make ObjectPropertyType visible to code outside
Dimitri Fontaine escribió:
Robert Haas robertmh...@gmail.com writes:
OK, I committed this.
Thanks. Please find attached a rebased patch, v6. I think it's looking
more like what you would expect now:
I gave this patch a look. I'm not done with it; I mostly gave the
utility.c changes some
Alvaro Herrera escribió:
I gave this patch a look. I'm not done with it; I mostly gave the
utility.c changes some love so that the end result is not as cluttered.
I did this by creating a couple of macros that call the Start() thing,
then set the OID, then call the End() thing. This made
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I gave this patch a look. I'm not done with it; I mostly gave the
utility.c changes some love so that the end result is not as cluttered.
Thanks Álvaro!
I did this by creating a couple of macros that call the Start() thing,
then set the OID,
Hi,
Peter Eisentraut pete...@gmx.net writes:
There is a new compiler warning coming from this, I believe:
I don't get this warning here, at least not in -O2, and I did forget to
make maintainer-clean then rebuild with -O0 just in case gcc is now
complaining about something else. I wish this
On Sun, 2012-12-30 at 13:18 +0100, Dimitri Fontaine wrote:
Peter Eisentraut pete...@gmx.net writes:
There is a new compiler warning coming from this, I believe:
I don't get this warning here, at least not in -O2, and I did forget to
make maintainer-clean then rebuild with -O0 just in case
On Tue, Dec 25, 2012 at 10:34 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Thank you for this partial commit, and Simon and Andres to fill in the
gaps. I should mention that the missing header parts were all in my
patch, and that headers hacking is proving suprisingly uneasy.
Apologies
On Tue, Dec 25, 2012 at 1:42 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
Also, keep in mind we want the ObjectID in all CREATE, ALTER and DROP
statements, so my current patch is still some bricks shy of a load… (I
added ObjectID only in the
Robert Haas robertmh...@gmail.com writes:
If I thought there were some useful code, I would try to see if we
could contribute it, but I'm pretty sure there isn't. We have a bunch
Oh. Too bad.
[... description of the tool ...]
I don't see a way to do the exact kind of testing we need here in
1 - 100 of 111 matches
Mail list logo
