From: Mason S. <mas...@en...> - 2010-05-13 01:13:13
|
Pavan Deolasee wrote: > > > On Wed, May 12, 2010 at 3:19 AM, Mason Sharp > <mas...@en... <mailto:mas...@en...>> > wrote: > > I started the task to recognize more "Postgres-XC safe" queries. > > I initially focused on native pg_catalog based views like > pg_settings. This is because it used by pgadmin. With the attached > patch, pgadmin no longer complains about such queries because they > are now supported. > > The PostgreSQL query rewriter appears to convert the view into a > subquery. I modified the XC planner to check for pg_catalog table > usage in the FROM clause (and subqueries thereof). > > > FWIW here are couple of things that I noticed: > > + foreach(item, rtable) > + { > + RangeTblEntry *rte = (RangeTblEntry *) lfirst(item); > + > + if (rte->rtekind == RTE_RELATION) > + { > + if (rte->relid > FirstNormalObjectId) > + return false; > + } else if (rte->rtekind == RTE_SUBQUERY) > + return contains_only_pg_catalog (rte->subquery->rtable); > + } > > This code will break out of the loop if the subquery contains only > pg_catalog tables. But other rtable entries may contain reference to > non-system tables. > > The other thing I am worried about is whether its safe to just rely on > FirstNormalObjectId to decide if a relation belongs to pg_catalog or > not. A user can create a table in pg_catalog (though I think it > requires changes to GUC) and that may get an OID larger than the > FirstNormalObjectId or we may add a new default schema and create > tables in the schema as part of initdb (we do that routinely in EDBAS > for example). Should we just explicitly lookup the namespace of the > relation instead ? > Thanks, I made those changes and committed. Mason > Thanks, > Pavan > > -- > Pavan Deolasee > EnterpriseDB http://www.enterprisedb.com -- Mason Sharp EnterpriseDB Corporation The Enterprise Postgres Company This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message. |