applied to the duplicated subtree twice.  Probably someday we should
fix the parser not to generate multiple links to the same subtree,
but for now a quick copyObject() is the path of least resistance.

(Don't forget that an alias is required.)  Views reimplemented as expanding
to subselect-in-FROM.  Grouping, aggregates, DISTINCT in views actually
work now (he says optimistically).  No UNION support in subselects/views
yet, but I have some ideas about that.  Rule-related permissions checking
moved out of rewriter and into executor.
INITDB REQUIRED!

ends to clean up (see my message of same date to pghackers), but mostly
it works.  INITDB REQUIRED!

for views. Views are now have a "relkind" of
RELKIND_VIEW instead of RELKIND_RELATION.

Also, views no longer have actual heap storage
files.

The following changes were made

1. CREATE VIEW sets the new relkind

2. The executor complains if a DELETE or
        INSERT references a view.

3. DROP RULE complains if an attempt is made
        to delete a view SELECT rule.

4. CREATE RULE "_RETmytable" AS ON SELECT TO mytable DO INSTEAD ...
        1. checks to make sure mytable is empty.
        2. sets the relkind to RELKIND_VIEW.
        3. deletes the heap storage files.
5. LOCK myview is not allowed. :)


6. the regression test type_sanity was changed to
        account for the new relkind value.

7. CREATE INDEX ON myview ... is not allowed.

8. VACUUM myview is not allowed.
        VACUUM automatically skips views when do the entire
        database.

9. TRUNCATE myview is not allowed.


THINGS LEFT TO THINK ABOUT

o pg_views

o pg_dump

o pgsql (\d \dv)
o Do we really want to be able to inherit from views?

o Is 'DROP TABLE myview' OK?

--
Mark Hollomon

Here's the multibyte aware version of my patch to fix the truncation
of the rulename autogenerated during a CREATE VIEW. I've modified all
the places in the backend that want to construct the rulename to use
the MakeRetrieveViewRuleName(), where I put the #ifdef MULTIBYTE, so
that's the only place that knows how to construct a view rulename. Except
pg_dump, where I replicated the code, since it's a standalone binary.

The only effect the enduser will see is that views with names len(name)
> NAMEDATALEN-4 will fail to be created, if the derived rulename clases
with an existing rule: i.e. the user is trying to create two views with
long names whose first difference is past NAMEDATALEN-4 (but before
NAMEDATALEN: that'll error out after the viewname truncation.) In no
case will the user get left with a table without a view rule, as the
current code does.

Ross Reedstrom

Don't go through pg_exec_query_dest(), but directly to the execution
routines.  Also, extend parameter lists so that there's no need to
change the global setting of allowSystemTableMods, a hack that was
certain to cause trouble in the event of any error.

compatiblity with old rules.

  SELECT a FROM t1 tx (a);
Allow join syntax, including queries like
  SELECT * FROM t1 NATURAL JOIN t2;
Update RTE structure to hold column aliases in an Attr structure.

  * Portions Copyright (c) 1996-2000, PostgreSQL, Inc

to all files copyright Regents of Berkeley.  Man, that's a lot of files.

mentioned in FROM but not elsewhere in the query: such tables should be
joined over anyway.  Aside from being more standards-compliant, this allows
removal of some very ugly hacks for COUNT(*) processing.  Also, allow
HAVING clause without aggregate functions, since SQL does.  Clean up
CREATE RULE statement-list syntax the same way Bruce just fixed the
main stmtmulti production.
CAUTION: addition of a field to RangeTblEntry nodes breaks stored rules;
you will have to initdb if you have any rules.

expressions in CREATE TABLE.  There is no longer an emasculated expression
syntax for these things; it's full a_expr for constraints, and b_expr
for defaults (unfortunately the fact that NOT NULL is a part of the
column constraint syntax causes a shift/reduce conflict if you try a_expr.
Oh well --- at least parenthesized boolean expressions work now).  Also,
stored expression for a column default is not pre-coerced to the column
type; we rely on transformInsertStatement to do that when the default is
actually used.  This means "f1 datetime default 'now'" behaves the way
people usually expect it to.
BTW, all the support code is now there to implement ALTER TABLE ADD
CONSTRAINT and ALTER TABLE ADD COLUMN with a default value.  I didn't
actually teach ALTER TABLE to call it, but it wouldn't be much work.

more cleanups...of note, appendStringInfo now performs like sprintf(),
where you state a format and arguments.  the old behavior required
each appendStringInfo to have to have a sprintf() before it if any
formatting was required.

Also shortened several instances where there were multiple appendStringInfo()
calls in a row, doing nothing more then adding one more word to the String,
instead of doing them all in one call.

Many more cleanups...

Initial attempt to clean up the code...

Switch sprintf() to snprintf()
Remove any/all #if 0 -or- #ifdef NOT_USED -or- #ifdef FALSE sections of
	code

        Fixes  a  bug  in  the rule system that caused a crashing
        backend when a join-view with calculated column  is  used
        in subselect.

        Modifies  EXPLAIN to explain rewritten queries instead of
        the plain SeqScan on a view. Rules can produce very  deep
MORE

Jan.

files.  Fix sequence creation hack for relkind type.

   now. Here some tested features, (examples included in the patch):

1.1) Subselects in the having clause 1.2) Double nested subselects
1.3) Subselects used in the where clause and in the having clause
     simultaneously 1.4) Union Selects using having 1.5) Indexes
on the base relations are used correctly 1.6) Unallowed Queries
are prevented (e.g. qualifications in the
     having clause that belong to the where clause) 1.7) Insert
into as select

2) Queries using the having clause on view relations also work
   but there are some restrictions:

2.1) Create View as Select ... Having ...; using base tables in
the select 2.1.1) The Query rewrite system:

2.1.2) Why are only simple queries allowed against a view from 2.1)
? 2.2) Select ... from testview1, testview2, ... having...; 3) Bug
in ExecMergeJoin ??


Regards Stefan