Kev <kevinjamesfi...@gmail.com> writes: > ... I was surprised > to find that some of my views of the form:
> select.........from b left join a on a.id=b.id > ...were being translated to this: > SELECT..........FROM (B LEFT JOIN a ON ((a.id = b.id))) > ...before being stored in the table pg_views is derived from. My > surprise is at the double parentheses around "a.id = b.id". Is that > supposed to be that way? Is it likely to change? There isn't any such "table". What pg_views is showing you is a reverse compilation of the internal parsetree for the rule. Whether there are parentheses in a given place is dependent on whether the code thinks it might be safe to omit them ... and I think in the non-prettyprinted format the answer is always "no". For instance with pg_views itself: regression=# select pg_get_viewdef('pg_views'::regclass); pg_get_viewdef ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ SELECT n.nspname AS schemaname, c.relname AS viewname, pg_get_userbyid(c.relowner) AS viewowner, pg_get_viewdef(c.oid) AS definition FROM (pg_class c LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind = 'v'::"char"); (1 row) regression=# select pg_get_viewdef('pg_views'::regclass, true); pg_get_viewdef --------------------------------------------------------------------------------------------------------------------------------------- SELECT n.nspname AS schemaname, c.relname AS viewname, pg_get_userbyid(c.relowner) AS viewowner, pg_get_viewdef(c.oid) AS definition FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind = 'v'::"char"; (1 row) Same parsetree, but the latter case is working a bit harder to make it look nice. The default case is overparenthesizing intentionally to make dead certain the rule will be parsed the same way if it's dumped and reloaded. 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