Re: [HACKERS] Inherited constraints and search paths (was Re:

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

In response to

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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