|
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.
|