From: | "Mark Hollomon" <mhh(at)nortelnetworks(dot)com> |
---|---|
To: | Jan Wieck <janwieck(at)Yahoo(dot)com> |
Cc: | Mike Mascari <mascarm(at)mascari(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Backend-internal SPI operations |
Date: | 2000-08-30 19:24:57 |
Message-ID: | 39AD5F89.834098B0@americasm01.nt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Jan Wieck wrote:
>
> Mark Hollomon wrote:
> > But I could be mistaken.
>
> Yep, you are.
D'oh.
> So far about history, now the future.
>
> Dumping views as CREATE VIEW is cleaner. It is possible now,
> since we dump the objects in OID order. So I like it. I see
> no problem with Tom's solution, changing the relkind and
> removing the files at CREATE RULE time for a couple of
> releases. And yes, dropping the SELECT rule from a view must
> be forbidden. As defining triggers, constraints and the like
> for them should be.
Alright. To recap.
1. CREATE VIEW sets relkind to RELKIND_VIEW
2. CREATE RULE ... AS ON SELECT DO INSTEAD ... sets relkind to RELKIND_VIEW
and deletes any relation files.
q: If we find an index, should we drop it, or complain, or ignore it?
q: Should the code check to see if the relation is empty (no valid tuples)?
3. DROP RULE complains if dropping the select rule for a view.
4. ALTER TABLE complains if run against a view.
Anything else?
--
Mark Hollomon
mhh(at)nortelnetworks(dot)com
ESN 451-9008 (302)454-9008
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-08-30 19:31:46 | Re: [BUG] calling lo_creat() |
Previous Message | Jan Wieck | 2000-08-30 19:01:26 | Re: Backend-internal SPI operations |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-08-30 20:28:12 | Re: Backend-internal SPI operations |
Previous Message | Jan Wieck | 2000-08-30 19:01:26 | Re: Backend-internal SPI operations |