From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Berend Tober <btober(at)seaworthysys(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Inherited constraints and search paths (was Re: |
Date: | 2005-05-20 21:31:18 |
Message-ID: | 3776.1116624678@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Berend Tober <btober(at)seaworthysys(dot)com> writes:
> However, when I do a select from a view, which itself does a select from
> a parent table, the query result does include the child table rows,
> i.e., the SQL_INHERITANCE setting is ignored in this situation. Should
> the SQL_INHERITANCE setting still rule?
I believe what matters is the sql_inheritance setting that was in force
when the view was created. You should be able to replace the view and
get it to do what you want.
(Hmm ... which suggests that we have still another pg_dump issue,
because views will be dumped using ONLY or no marker, and so reloading
them into a server with SQL_INHERITANCE off would result in a change in
the view behavior. Probably we need to put "SET SQL_INHERITANCE = ON"
into the standard prologue of pg_dump scripts.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ed L. | 2005-05-20 21:54:28 | Re: [GENERAL] Image storage questions |
Previous Message | Matthew Hixson | 2005-05-20 21:29:31 | GCC 4.0 on Mac OS X |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2005-05-20 21:33:46 | Re: patches for items from TODO list |
Previous Message | Berend Tober | 2005-05-20 21:25:29 | Re: [HACKERS] Inherited constraints and search paths (was |