Kohei KaiGai <kai...@kaigai.gr.jp> writes: > 2013/2/14 Tom Lane <t...@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.1331223...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers