Re: AW: AW: Backend-internal SPI operations

Zeugswetter Andreas SB wrote:
>
> > Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
> > > I don't see why a real view should still be createable by the old
> > > create table then create rule way.
> >
> > Because we'll need to be able to read dump files created by existing
> > versions of pg_dump. If we don't cope with CREATE TABLE + CREATE RULE
> > then restored-from-dump views won't really be views and will act
> > differently from freshly created views. Avoiding the resulting
> > support headaches is worth a little bit of ugliness in the code.
>
> Well, since an on select do instead rule on a whole table is offhand
> only good for a view I do agree. (At least I can't think of another use)
>
> The only worry I have is that it should not destroy the possibility for real
>
> on select do instead rules on single attributes.

Andreas,

The rule system we got from Berkeley was "brittle and broken"
(as the original docs say).

6.4 was the first release with a rule system that was useful
for things other than views.

With 6.4 I restricted rules ON SELECT to:

- must be INSTEAD
- must NOT be conditional
- must have exactly one SELECT query as action
- the action must return a targetlist identical to the
table layout they are fired for
- must be named "_RET<tablename>".

Yes, that is a VIEW, a whole VIEW and nothing but a VIEW, so
help me God.

We don't have any other ON SELECT rules than views - for
years now. And I'm not sure if the concept of single
attribute rules ON SELECT could ever be implemented in the
rewriter. It's already complicated enough with view rules,
and I remember the sleepless nights well enough not to try.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #