On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Robert Haas <robertmhaas@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?"