Shigeru Hanada <shigeru.hanada@gmail.com> writes:
> On Fri, Feb 15, 2013 at 12:58 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> [ rereads that... ] Hm, I did make some good points. But having seen
>> the end result of this way, I'm still not very happy; it still looks
>> like a maintenance problem. Maybe some additional flags in ruleutils.c
>> is the least evil way after all. Needs more thought.
> I'm working on revising deparser so that it uses ruleutils routines to
> construct remote query, and re-found an FDW-specific problem which I
> encountered some months ago.
After further review I'm unconvinced that we can really do much better
than what's there now --- the idea of sharing code with ruleutils sounds
attractive, but once you look at all the specific issues that ruleutils
would have to be taught about, it gets much less so. (In particular
I fear we'll find that we have to do some weird stuff to deal with
cross-server-version issues.) I've been revising the patch on the
assumption that we'll keep deparse.c more or less as is.
Having said that, I remain pretty unhappy with the namespace handling in
deparse.c. I don't think it serves much purpose to schema-qualify
everything when we're restricting what we can access to built-in
operators and functions --- the loss of readability outweighs the
benefits IMO. Also, there is very little point in schema-qualifying
almost everything rather than everything; if you're not 100% then you
have no safety against search_path issues. But that's what we've got
because the code still relies on format_type to print type names.
Now we could get around that complaint by duplicating format_type as
well as ruleutils, but I don't think that's the right direction to
proceed. I still think it might be a good idea to set search_path to
pg_catalog on the remote side, and then schema-qualify only what is not
in pg_catalog (which would be nothing, in the current code, so far as
types/functions/operators are concerned).
regards, tom lane
