database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Remove logic for converting a table to a view.

Browse Source 
Up to now we have allowed manual creation of an ON SELECT rule on
a table to convert it into a view.  That was never anything but a
horrid, error-prone hack though.  pg_dump used to rely on that
behavior to deal with cases involving circular dependencies,
where a dependency loop could be broken by separating the creation
of a view from installation of its ON SELECT rule.  However, we
changed pg_dump to use CREATE OR REPLACE VIEW for that in commit
d8c05aff5 (which was later back-patched as far as 9.4), so there's
not a good argument anymore for continuing to support the behavior.

The proximate reason for axing it now is that we found that the
new statistics code has failure modes associated with the relkind
change caused by this behavior.  We'll patch around that in v15,
but going forward it seems like a better idea to get rid of the
need to support relkind changes.

Discussion: https://postgr.es/m/CALDaNm2yXz+zOtv7y5zBd5WKT8O0Ld3YxikuU3dcyCvxF7gypA@mail.gmail.com
This commit is contained in:
Tom Lane
2022-12-02 12:14:32 -05:00
parent 66456da150
commit b23cd185fd
8 changed files with 45 additions and 305 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
doc/src/sgml/rules.sgml
View File

@ -280,14 +280,16 @@
<para>
Views in <productname>PostgreSQL</productname> are implemented
using the rule system. In fact, there is essentially no difference
between:
using the rule system. A view is basically an empty table (having no
actual storage) with an <literal>ON SELECT DO INSTEAD</literal> rule.
Conventionally, that rule is named <literal>_RETURN</literal>.
So a view like
<programlisting>
CREATE VIEW myview AS SELECT * FROM mytab;
</programlisting>
compared against the two commands:
is very nearly the same thing as
<programlisting>
CREATE TABLE myview (<replaceable>same column list as mytab</replaceable>);
@ -295,13 +297,17 @@ CREATE RULE "_RETURN" AS ON SELECT TO myview DO INSTEAD
SELECT * FROM mytab;
</programlisting>
because this is exactly what the <command>CREATE VIEW</command>
command does internally. This has some side effects. One of them
is that the information about a view in the
<productname>PostgreSQL</productname> system catalogs is exactly
the same as it is for a table. So for the parser, there is
absolutely no difference between a table and a view. They are the
same thing: relations.
although you can't actually write that, because tables are not
allowed to have <literal>ON SELECT</literal> rules.
</para>
<para>
A view can also have other kinds of <literal>DO INSTEAD</literal>
rules, allowing <command>INSERT</command>, <command>UPDATE</command>,
or <command>DELETE</command> commands to be performed on the view
despite its lack of underlying storage.
This is discussed further below, in
<xref linkend="rules-views-update"/>.
</para>
<sect2 id="rules-select">
@ -1111,7 +1117,7 @@ SELECT word FROM words ORDER BY word &lt;-&gt; 'caterpiler' LIMIT 10;
<para>
Rules that are defined on <command>INSERT</command>, <command>UPDATE</command>,
and <command>DELETE</command> are significantly different from the view rules
described in the previous section. First, their <command>CREATE
described in the previous sections. First, their <command>CREATE
RULE</command> command allows more:
<itemizedlist>