Christopher Browne 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 ddl_command_end event, then
On Mon, Jan 28, 2013 at 6:19 PM, Dimitri Fontaine
wrote:
> Christopher Browne 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
Christopher Browne 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 set up some eve
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, and
Robert Haas 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 switch. Read some mo
On Sun, Jan 27, 2013 at 12:57 PM, Dimitri Fontaine
wrote:
> Robert Haas 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 s
Robert Haas 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 the implement
On Sun, Jan 27, 2013 at 12:08 PM, Steve Singer wrote:
> On 13-01-26 11:11 PM, Robert Haas wrote:
>> On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
>> wrote:
>>>
>>> My understanding is that if the command string we give to event triggers
>>> is ambiguous (sub-object names, schema qualificatio
On 13-01-26 11:11 PM, Robert Haas wrote:
On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
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
On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
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
> that to speak up n
On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
wrote:
> Robert Haas 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)
>>
Robert Haas 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 some people. Argu
On Thu, Jan 24, 2013 at 5:43 AM, Dimitri Fontaine
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 the same as ext
[ changing subject line to keep threads of discussion separate ]
On Thu, Jan 24, 2013 at 5:51 AM, Dimitri Fontaine
wrote:
> Something like this part:
>
> + -- now try something crazy to ensure we don't crash the backend
> + create function test_event_trigger_drop_function()
> + returns event_tri
On 13-01-24 05:43 AM, Dimitri Fontaine wrote:
Robert Haas writes:
On Mon, Jan 21, 2013 at 12:27 PM, Dimitri Fontaine
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 ju
Robert Haas 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()
+ returns event_tri
Robert Haas writes:
> On Mon, Jan 21, 2013 at 12:27 PM, Dimitri Fontaine
> 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
> throwing random junk into ProcessUt
Robert Haas 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 due to Snapshot
On Wed, Jan 23, 2013 at 03:02:24PM -0500, Robert Haas wrote:
> On Wed, Jan 23, 2013 at 2:36 PM, Bruce Momjian 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
> >> wrote:
> >> > Thanks for commiting the fixes. About the
On Wed, Jan 23, 2013 at 2:36 PM, Bruce Momjian 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
>> wrote:
>> > Thanks for commiting the fixes. About the regression tests, I think
>> > you're right, but then I can't see how
On Wed, Jan 23, 2013 at 09:33:58AM -0500, Robert Haas wrote:
> On Wed, Jan 23, 2013 at 4:57 AM, Dimitri Fontaine
> 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
On Wed, Jan 23, 2013 at 4:57 AM, Dimitri Fontaine
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 you have in mind so I
Robert Haas 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.
Thanks for commiting
On Mon, Jan 21, 2013 at 12:27 PM, Dimitri Fontaine
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 existing consumers of th
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
> wrote:
>
> ...unless I've coincidentally stumbled upon the new MEOW LIKE A CAT
> command coming in 9.3. ;)
>
> +1
On 23/01/13 16:02, Robert Haas wrote:
On Tue, Jan 22, 2013 at 11:38 AM, Thom Brown 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, please Please, PLEAS
On Tue, Jan 22, 2013 at 11:38 AM, Thom Brown 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 PostgreSQL Company
On Tue, Jan 22, 2013 at 7:02 AM, Dimitri Fontaine
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
people to get. Can we a
On Tue, Jan 22, 2013 at 7:29 AM, Dimitri Fontaine
wrote:
> Dimitri Fontaine 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 2013-01-18 17:20:51 -0500, Robert Haas wrote:
> On Fri, Jan 18, 2013 at 5:12 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane wrote:
> >>> Well, that burden already exists for non-utility statements --- why
> >>> should utility statements get a pass?
Thom Brown 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. ;)
Oe N
Thom Brown 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
> dropping a c
On 22 January 2013 16:28, Thom Brown wrote:
> On 22 January 2013 14:47, Thom Brown 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 this works now. The d
On 22 January 2013 14:47, Thom Brown wrote:
> On 22 January 2013 14:45, Dimitri Fontaine wrote:
>> Thom Brown 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
On 22 January 2013 14:45, Dimitri Fontaine wrote:
> Thom Brown 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/s
Thom Brown 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
b/doc/src/sgml/ref/creat
On 22 January 2013 13:28, Dimitri Fontaine wrote:
> Thom Brown 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, I had misunderstood something
Thom Brown 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 which doesn'
On 22 January 2013 12:02, Dimitri Fontaine wrote:
>
> "Dickson S. Guedes" writes:
> > 2013/1/21 Robert Haas :
> >> 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,
Dimitri Fontaine 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 +++
> src/test/regress/sql/event_trigger.sql
Robert Haas 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 ddl_command_start
> and ddl_co
2013/1/21 Robert Haas :
> 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 not bear mentioning
On Mon, Jan 21, 2013 at 12:27 PM, Dimitri Fontaine
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
patch left me with a slig
Robert Haas 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
doc/src/sgml/event-trigger.sgml
On Fri, Jan 18, 2013 at 5:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane 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 f
Robert Haas writes:
> On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane 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 good thing to discourage
>> anyh
On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane wrote:
> Alvaro Herrera 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
>>>
Alvaro Herrera 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
>> https://github.com/dimitri/postgres/blob/d2996303c7bc6daa
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
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
> > i
On 2013-01-18 12:44:13 -0500, Tom Lane wrote:
> Andres Freund 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->DD
Andres Freund 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 clear, sorry for
On 2013-01-18 11:42:47 -0500, Robert Haas wrote:
> On Fri, Jan 18, 2013 at 10:47 AM, Andres Freund
> 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 ob
On Fri, Jan 18, 2013 at 10:47 AM, Andres Freund 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 type - table, col
On 2013-01-18 09:58:53 -0500, Robert Haas wrote:
> On Fri, Jan 18, 2013 at 9:07 AM, Andres Freund 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, so you probably
On 18 January 2013 02:48, Tom Lane wrote:
> Andres Freund 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
On Fri, Jan 18, 2013 at 9:07 AM, Andres Freund wrote:
> On 2013-01-17 22:39:18 -0500, Robert Haas wrote:
>> On Thu, Jan 17, 2013 at 8:33 PM, 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. T
On 2013-01-17 22:39:18 -0500, Robert Haas wrote:
> On Thu, Jan 17, 2013 at 8:33 PM, 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
Tom Lane writes:
> Robert Haas 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 just like a new command, so it
On Thu, Jan 17, 2013 at 8:33 PM, 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 informati
Andres Freund 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 (or at
>> least
On 2013-01-17 21:48:01 -0500, Tom Lane wrote:
> Andres Freund 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
>
Andres Freund 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 actually recreate the DDL
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 wit
Robert Haas writes:
> On Thu, Jan 17, 2013 at 4:43 PM, Dimitri Fontaine
> 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 faith. If you execute a
> command 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
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 actu
On 01/18/2013 04:24 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On 17 January 2013 16:15, Robert Haas 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 cle
On 2013-01-17 23:48:23 +0100, Dimitri Fontaine wrote:
> Tom Lane 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 just put
>
On Thu, Jan 17, 2013 at 5:09 PM, Tom Lane 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 locking all
On Thu, Jan 17, 2013 at 4:43 PM, Dimitri Fontaine
wrote:
> Robert Haas 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
>> alter
Dimitri Fontaine writes:
> Tom Lane 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.
Tom Lane 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 that random to m
Simon Riggs writes:
> On 17 January 2013 20:24, Tom Lane 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 table with a serial column also crea
Dimitri Fontaine writes:
> Tom Lane 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 about ddl_command_start and ddl_comm
Robert Haas 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 for an ALTER ]
Re
On 17 January 2013 20:24, Tom Lane wrote:
> Simon Riggs writes:
>> On 17 January 2013 16:15, Robert Haas 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
Tom Lane 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 to consider, a
Robert Haas 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 terms of the propo
On Thu, Jan 17, 2013 at 12:06 PM, Dimitri Fontaine
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 before, it
>> exposes
Simon Riggs writes:
> On 17 January 2013 16:15, Robert Haas 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 difference seems very
>> clear-cut to
On 17 January 2013 16:15, 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 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 ddl_command_end.
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)
On Thu, Jan 17, 2013 at 5:18 AM, Dimitri Fontaine
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:
- adds ddl_command_trace
Robert Haas 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 expose new
> informat
On Wed, Jan 16, 2013 at 6:14 PM, Tom Lane 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 that role for eve
Dimitri Fontaine 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 like the next
On Wed, Jan 16, 2013 at 4:16 PM, Dimitri Fontaine
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 author didn't thin
Robert Haas 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 talk about our pro
On Wed, Jan 9, 2013 at 11:58 AM, Alvaro Herrera
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 improving
> some stuff
Dimitri Fontaine escribió:
> Alvaro Herrera 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
> > objectaddress.
Alvaro Herrera 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, then call the End() th
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
Dimitri Fontaine escribió:
> Robert Haas 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 love so that the
On Sun, 2012-12-30 at 13:18 +0100, Dimitri Fontaine wrote:
> Peter Eisentraut 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
Hi,
Peter Eisentraut 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 situation could be
On Sat, 2012-12-29 at 08:11 -0500, Robert Haas wrote:
> On Tue, Dec 25, 2012 at 1:42 PM, Dimitri Fontaine
> wrote:
> > Robert Haas 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
> >>>
Robert Haas writes:
> The other danger here is - what exactly do you mean by "no command has
> been able to run between the user command and our lookup"? Because
> you can do stupid things with functions like set_config(). This would
> only be safe if no user-provided expressions can possibly ge
On 12/29/2012 08:41 AM, Dimitri Fontaine wrote:
Well, do we have \! in psql in windows at all? does it work in a similar
way to the unix one? I just don't know.
Of course we do, Why ever would you think we don't? The command must be
written in the Windows shell language, but the behaviour i
1 - 100 of 111 matches
Mail list logo
