Re: Backend-internal SPI operations

Mark Hollomon wrote:
> Mike Mascari wrote:
> >
> > Tom Lane wrote:
> > >
> > > Jan Wieck <janwieck(at)Yahoo(dot)com> writes:
> > > > From memory I think views are created as CREATE TABLE, with
> > > > an internal DefineRuleStmt, and dumped as CREATE TABLE,
> > > > CREATE RULE for sure. So the CREATE/DROP RULE would need to
> > > > remove/recreate the tables file (plus toast file and index)
> > > > if you want it to be consistent. Don't think you want that -
> > > > do you?
> > >
> > > But that's only true because it's such a pain in the neck for pg_dump
> > > to discover that a table is a view. If this could easily be told from
> > > inspection of pg_class, then it'd be no problem to dump views as
> > > CREATE VIEW statements in the first place --- obviously better, no?
> >
> > The fact that views can be created by a separate table/rule
> > sequence allows pg_dump to properly dump views which are based
> > upon functions, or views which may have dependencies on other
> > tables/views.
>
> I don't see this. a 'CREATE VIEW' cannot reference a function that
> did not exist at the time it was executed. The only way to get in
> trouble, that I see, is a DROP/CREATE RULE. But I think
> the proposal is not to allow this to happen if the rule is the
> select rule for a view.
>
> The reason that pg_dump used the table/rule sequence was that historically
> it was hard to figure out that a tuple in pg_class really represented a
> view.
>
> But I could be mistaken.

Yep, you are.

The reason why we dump views as table+rule is that
historically we wheren't able to dump views and rules at all.
We only store the parsetree representation of rules, since
epoch. Then, someone wrote a little backend function that's
able to backparse these rule actions. It got enhanced by a
couple of other smart guys and got used by pg_dump. At that
time, it was right to dump views as table+rule, because
pg_dump didn't do anything in OID order. So views using sql
functions using views in turn wouldn't be dumpable otherwise.
And it was easier too because it was already done after
dumping rules at the end. No need to do anything else for
views :-)

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.

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 #