Re: [HACKERS] replicating DROP commands across servers

2015-01-12 Thread Alvaro Herrera
Jeff Janes wrote: On Fri, Jan 2, 2015 at 9:59 PM, Jeff Janes jeff.ja...@gmail.com wrote: This commit 3f88672a4e4d8e648d24ccc65 seems to have broken pg_upgrade for pg_trgm. It seems I failed to notice the get_object_address in the ALTER EXTENSION path. Should be fixed now. I looked for

Re: [HACKERS] replicating DROP commands across servers

2015-01-05 Thread Jeff Janes
On Fri, Jan 2, 2015 at 9:59 PM, Jeff Janes jeff.ja...@gmail.com wrote: On Mon, Dec 29, 2014 at 2:15 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Here's a patch that tweaks the grammar to use TypeName in COMMENT, SECURITY LABEL, and DROP for the type and domain cases. The required

Re: [HACKERS] replicating DROP commands across servers

2015-01-02 Thread Jeff Janes
On Mon, Dec 29, 2014 at 2:15 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Here's a patch that tweaks the grammar to use TypeName in COMMENT, SECURITY LABEL, and DROP for the type and domain cases. The required changes in the code are pretty minimal, thankfully. Note the slight changes

Re: [HACKERS] replicating DROP commands across servers

2014-12-29 Thread Alvaro Herrera
Alvaro Herrera wrote: Patch 0005 adds getObjectIdentityParts(), which returns the object identity in arrays that can be passed to pg_get_object_address. This part needs slight revisions so I'm not sure I will be able to push tomorrow. Here's a fresh version of this patch. I chose to add a

Re: [HACKERS] replicating DROP commands across servers

2014-12-29 Thread Alvaro Herrera
(The changes in the regression test are bogus, BTW; I didn't care enough to get them fixed before sorting out the rest of the mess.) -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training Services commit

Re: [HACKERS] replicating DROP commands across servers

2014-12-29 Thread Alvaro Herrera
Here's a patch that tweaks the grammar to use TypeName in COMMENT, SECURITY LABEL, and DROP for the type and domain cases. The required changes in the code are pretty minimal, thankfully. Note the slight changes to the new object_address test also. I think I'm pretty much done with this now, so

Re: [HACKERS] replicating DROP commands across servers

2014-12-24 Thread Andres Freund
On 2014-12-24 21:54:20 +1300, David Rowley wrote: On 24 December 2014 at 07:41, Alvaro Herrera alvhe...@2ndquadrant.com wrote: I have pushed patches 0001 through 0004, with some revisions. Only the final part is missing. Hi Alvaro, Would you be able to commit the attached? It just

Re: [HACKERS] replicating DROP commands across servers

2014-12-24 Thread David Rowley
On 25 December 2014 at 00:34, Andres Freund and...@2ndquadrant.com wrote: On 2014-12-24 21:54:20 +1300, David Rowley wrote: On 24 December 2014 at 07:41, Alvaro Herrera alvhe...@2ndquadrant.com wrote: I have pushed patches 0001 through 0004, with some revisions. Only the final part

Re: [HACKERS] replicating DROP commands across servers

2014-12-24 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: I really wonder if we can't make msvc reliably recognize this kind of scenario - especially this case is pretty trivial? Even if MSVC did understand pg_unreachable(), there would be other compilers that didn't, so we'd need to worry about suppressing

Re: [HACKERS] replicating DROP commands across servers

2014-12-24 Thread Tom Lane
David Rowley dgrow...@gmail.com writes: On 25 December 2014 at 00:34, Andres Freund and...@2ndquadrant.com wrote: I really wonder if we can't make msvc reliably recognize this kind of scenario - especially this case is pretty trivial? The attached patch removes the warning, but likely can't

Re: [HACKERS] replicating DROP commands across servers

2014-12-24 Thread David Rowley
On 25 December 2014 at 04:47, Tom Lane t...@sss.pgh.pa.us wrote: David Rowley dgrow...@gmail.com writes: On 25 December 2014 at 00:34, Andres Freund and...@2ndquadrant.com wrote: I really wonder if we can't make msvc reliably recognize this kind of scenario - especially this case is

Re: [HACKERS] replicating DROP commands across servers

2014-12-23 Thread Alvaro Herrera
I have pushed patches 0001 through 0004, with some revisions. Only the final part is missing. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] replicating DROP commands across servers

2014-12-22 Thread Alvaro Herrera
Here's a five-part split of the remaining pieces of this patch. Patch 0001 is the one I posted in http://www.postgresql.org/message-id/20141220022308.gy1...@alvh.no-ip.org which adds support for COMMENT ON CONSTRAINT .. ON DOMAIN. This just splits OBJECT_CONSTRAINT in OBJECT_TABCONSTRAINT and

Re: [HACKERS] replicating DROP commands across servers

2014-12-19 Thread Alvaro Herrera
Alvaro Herrera wrote: Alvaro Herrera wrote: Andres Freund wrote: Having reread the patch just now I basically see two things to criticize: a) why isn't this accessible at SQL level? That seems easy to address. b) Arguably some of this could well be done in separate commits.

Re: [HACKERS] replicating DROP commands across servers

2014-12-15 Thread Alvaro Herrera
Michael Paquier wrote: This patch has had no activity for the last two months, is in Needs Review state and has marked as reviewer Dimitri. As there is no activity from the reviewer, I am moving that to CF 2014-12 and removing Dimitri as reviewer. If someone wants to have a look at this

Re: [HACKERS] replicating DROP commands across servers

2014-10-15 Thread Andres Freund
On 2014-10-04 21:12:24 -0400, Robert Haas wrote: On Fri, Oct 3, 2014 at 4:58 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Robert Haas wrote: I'm not really very convinced that it's a good idea to expose this instead of just figuring out a way to parse the object identity. That's

Re: [HACKERS] replicating DROP commands across servers

2014-10-15 Thread Alvaro Herrera
Andres Freund wrote: Having reread the patch just now I basically see two things to criticize: a) why isn't this accessible at SQL level? That seems easy to address. b) Arguably some of this could well be done in separate commits. Fair comments. I will split it up. FWIW, I spent some time

Re: [HACKERS] replicating DROP commands across servers

2014-10-15 Thread Alvaro Herrera
Alvaro Herrera wrote: Andres Freund wrote: Having reread the patch just now I basically see two things to criticize: a) why isn't this accessible at SQL level? That seems easy to address. b) Arguably some of this could well be done in separate commits. Fair comments. I will split it

Re: [HACKERS] replicating DROP commands across servers

2014-10-14 Thread Alvaro Herrera
Robert Haas wrote: On Fri, Oct 3, 2014 at 4:58 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Robert Haas wrote: I'm not really very convinced that it's a good idea to expose this instead of just figuring out a way to parse the object identity. That's the first thing I tried. But

Re: [HACKERS] replicating DROP commands across servers

2014-10-09 Thread Jim Nasby
On 10/6/14, 11:24 PM, Robert Haas wrote: Offlist. FWIW, I've run into situations more than once in userspace where I need a way to properly separate schema and object name. Generally I can make do using reg* casts and then hitting catalog tables, but it'd be nice if there was an easier way.

Re: [HACKERS] replicating DROP commands across servers

2014-10-09 Thread Alvaro Herrera
Jim Nasby wrote: On 10/6/14, 11:24 PM, Robert Haas wrote: Offlist. FWIW, I've run into situations more than once in userspace where I need a way to properly separate schema and object name. Generally I can make do using reg* casts and then hitting catalog tables, but it'd be nice if there

Re: [HACKERS] replicating DROP commands across servers

2014-10-06 Thread Jim Nasby
On 10/4/14, 8:12 PM, Robert Haas wrote: It's just not sane to try to parse such text strings. But this is a pretty ridiculous argument. We have an existing parser that does it just fine, and a special-purpose parser that does just that (and not all of the other stuff that the main parser does)

Re: [HACKERS] replicating DROP commands across servers

2014-10-04 Thread Robert Haas
On Fri, Oct 3, 2014 at 4:58 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Robert Haas wrote: I'm not really very convinced that it's a good idea to expose this instead of just figuring out a way to parse the object identity. That's the first thing I tried. But it's not pretty: you have

Re: [HACKERS] replicating DROP commands across servers

2014-10-03 Thread Heikki Linnakangas
On 09/16/2014 09:09 PM, Brightwell, Adam wrote: I think there's been some changes to this patch since july, care to resend a new version? Sure, here it is. The only difference with the previous version is that it now also supports column defaults. This was found to be a problem when you

Re: [HACKERS] replicating DROP commands across servers

2014-10-03 Thread Alvaro Herrera
Heikki Linnakangas wrote: On 09/16/2014 09:09 PM, Brightwell, Adam wrote: I have given this patch the following review: - Apply to current master (77e65bf). -- success - check-world. --success - multiple FIXME statements still exist -- are there plans to fix these items? Can the

Re: [HACKERS] replicating DROP commands across servers

2014-10-03 Thread Stephen Frost
Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: There are three fixmes in the code. One can be handled by just removing the line; we don't really care about duplicating 10 lines of boilerplate code. The other two mean missing support for domain constraints and for default ACLs.

Re: [HACKERS] replicating DROP commands across servers

2014-10-03 Thread Heikki Linnakangas
On 10/03/2014 08:08 PM, Stephen Frost wrote: Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: There are three fixmes in the code. One can be handled by just removing the line; we don't really care about duplicating 10 lines of boilerplate code. The other two mean missing support

Re: [HACKERS] replicating DROP commands across servers

2014-10-03 Thread Alvaro Herrera
Heikki Linnakangas wrote: I had a very brief look at the docs, and these extra outputs from pg_event_trigger_dropped_objects caught my eye: +row + entryliteraladdress_names/literal/entry + entrytypetext[]/type/entry + entry + An array that,

Re: [HACKERS] replicating DROP commands across servers

2014-10-03 Thread Heikki Linnakangas
On 10/03/2014 09:06 PM, Alvaro Herrera wrote: Heikki Linnakangas wrote: I had a very brief look at the docs, and these extra outputs from pg_event_trigger_dropped_objects caught my eye: +row + entryliteraladdress_names/literal/entry + entrytypetext[]/type/entry +

Re: [HACKERS] replicating DROP commands across servers

2014-10-03 Thread Alvaro Herrera
Heikki Linnakangas wrote: On 10/03/2014 09:06 PM, Alvaro Herrera wrote: Well, the return value from get_object_address is an ObjectAddress. It's simple enough to create an SQL wrapper that takes the address_names/address_args arrays and return an ObjectAddress; would this be useful? An

Re: [HACKERS] replicating DROP commands across servers

2014-10-03 Thread Alvaro Herrera
Alvaro Herrera wrote: Precisely the point is not returning those values, because they are useless to identify the equivalent object in a remote database. What we need is the object names and other stuff used to uniquely identify it by user-visible name. We transmit those name arrays to a

Re: [HACKERS] replicating DROP commands across servers

2014-10-03 Thread Stephen Frost
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: Right. In the add to objname cases, there is already some other routine that initialized it previously by filling in some stuff; in the case above, this happens in the getRelationIdentity() immediately preceding this. In the other cases we

Re: [HACKERS] replicating DROP commands across servers

2014-10-03 Thread Alvaro Herrera
Stephen Frost wrote: * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: Right. In the add to objname cases, there is already some other routine that initialized it previously by filling in some stuff; in the case above, this happens in the getRelationIdentity() immediately preceding

Re: [HACKERS] replicating DROP commands across servers

2014-10-03 Thread Stephen Frost
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: Stephen Frost wrote: ahh, ok, that makes a bit more sense, sorry for missing it. Still makes me wonder why objargs gets special treatment at the top of the function and objnames doesn't- seems like both should be initialized either

Re: [HACKERS] replicating DROP commands across servers

2014-10-03 Thread Robert Haas
On Fri, Oct 3, 2014 at 2:33 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Heikki Linnakangas wrote: On 10/03/2014 09:06 PM, Alvaro Herrera wrote: Well, the return value from get_object_address is an ObjectAddress. It's simple enough to create an SQL wrapper that takes the

Re: [HACKERS] replicating DROP commands across servers

2014-10-03 Thread Alvaro Herrera
Robert Haas wrote: I'm not really very convinced that it's a good idea to expose this instead of just figuring out a way to parse the object identity. That's the first thing I tried. But it's not pretty: you have to extract schema names by splitting at a period (and what if a schema name

Re: [HACKERS] replicating DROP commands across servers

2014-10-03 Thread Andres Freund
On 2014-10-03 14:02:09 -0300, Alvaro Herrera wrote: Since the patch has had good feedback and no further comments arise, I can just implement support for those two missing object types and push, and everybody will be happy. Right? I'd like to see a new version before that out here... I don't

Re: [HACKERS] replicating DROP commands across servers

2014-09-16 Thread Brightwell, Adam
I think there's been some changes to this patch since july, care to resend a new version? Sure, here it is. The only difference with the previous version is that it now also supports column defaults. This was found to be a problem when you drop a sequence that some column default

Re: [HACKERS] replicating DROP commands across servers

2014-08-26 Thread Andres Freund
On 2014-06-13 15:50:50 -0400, Alvaro Herrera wrote: Here's a patch implementing the proposed idea. This is used in the Bidirectional Replication stuff by Simon/Andres; it works well. I think there's been some changes to this patch since july, care to resend a new version? I think it's

Re: [HACKERS] replicating DROP commands across servers

2014-08-26 Thread Alvaro Herrera
Andres Freund wrote: On 2014-06-13 15:50:50 -0400, Alvaro Herrera wrote: Here's a patch implementing the proposed idea. This is used in the Bidirectional Replication stuff by Simon/Andres; it works well. I think there's been some changes to this patch since july, care to resend a new

Re: [HACKERS] replicating DROP commands across servers

2014-06-30 Thread Abhijit Menon-Sen
Hi. I thought I'd review this patch, since pgaudit uses the pg_event_trigger_dropped_objects function. I went through the patch line by line, and I don't really have anything to say about it. I notice that there are some XXX/FIXME comments in the code, but it's not clear if those need to (or can

Re: [HACKERS] replicating DROP commands across servers

2014-06-13 Thread Alvaro Herrera
Here's a patch implementing the proposed idea. This is used in the Bidirectional Replication stuff by Simon/Andres; it works well. One thing of note is that I added output flags for normal and original, which mostly come from performDeletion flags. This let one select only such objects when

[HACKERS] replicating DROP commands across servers

2014-03-28 Thread Alvaro Herrera
As you probably know, I've studying how to implement a system to allow replicating DDL commands to remote servers. I have a fairly good grasp of handling CREATE commands; we have another thread discussing that involving a JSON output for such commands. That hasn't been carried to completion yet;

Re: [HACKERS] replicating DROP commands across servers

2014-03-28 Thread Tom Lane
Alvaro Herrera alvhe...@2ndquadrant.com writes: My proposal therefore is to add some more columns to pg_event_trigger_dropped_objects(): more precisely, objname and objargs, which would carry exactly what get_object_address() would require to re-construct an ObjectAddress for the object being

Re: [HACKERS] replicating DROP commands across servers

2014-03-28 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com writes: My proposal therefore is to add some more columns to pg_event_trigger_dropped_objects(): more precisely, objname and objargs, which would carry exactly what get_object_address() would require to re-construct an ObjectAddress