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.
So far ruleutils routines require "deparse context", which is a list
of namespace information. Currently deparse_context_for() seems to
fit postgres_fdw's purpose, but it always uses names stored in
catalogs (pg_class, pg_attribute and pg_namespace), though
postgres_fdw wants to replace column/table/schema name with the name
specified in relevant FDW options if any.
Proper remote query will be generated If postgres_fdw can modify
deparse context, but deparse_context is hidden detail of ruleutils.c.
IMO disclosing it is bad idea.
Given these, I'm thinking to add new deparse context generator which
basically construct namespaces from catalogs, but replace one if FDW
option *_name was specified for an object. With this context,
existing ruleutils would generate expression-strings with proper
names, without any change.
Is this idea acceptable?
--
Shigeru HANADA