Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
> 2013/2/14 Tom Lane <tgl@sss.pgh.pa.us>:
>> * deparse.c contains a depressingly large amount of duplication of logic
>> from ruleutils.c, and can only need more as we expand the set of
>> constructs that can be pushed to the remote end. This doesn't seem like
>> a maintainable approach. Was there a specific reason not to try to use
>> ruleutils.c for this?
> Previously, you suggested to implement its own logic for query deparsing,
> then Hanada-san rewrite the relevant code.
> http://www.postgresql.org/message-id/12181.1331223482@sss.pgh.pa.us
[ 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.
> Indeed, most of the logic is duplicated. However, it is to avoid bugs in
> some corner cases, for instance, function name is not qualified with
> schema even if this function is owned by different schema in remote side.
That particular reason doesn't seem to hold a lot of water when we're
restricting the code to only push over built-in functions/operators
anyway.
I find it tempting to think about setting search_path explicitly to
"pg_catalog" (only) on the remote side, whereupon we'd have to
explicitly schema-qualify references to user tables, but built-in
functions/operators would not need that (and it wouldn't really matter
if ruleutils did try to qualify them).
regards, tom lane
