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 would be (1) very easy to do, (2) >> reasonable to slip into 9.3, and (3) useful to some people. Arguably, >> the normalized command string would be useful to MORE people, but I >> think the raw command string is not without its uses, and it's at >> least one order of magnitude less work. > > 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 now.
"Useless" is a strong word, but it certainly injures usefulness pretty substantially. If it isn't normalized, then either we accept that: a) If you fail to properly qualify your inputs, when generating DDL, we can offer that it's pretty likely it'll all smash on the floor when we try to replicate it, or b) We need to capture the active search_path from the environment at the instant of the DDL capture event, and carry it over along with the DDL. If we could assume that the GUC, search_path, was the correct value, that's possibly not super difficult, but I'm not certain that's the correct thing to capture. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
