Andres Freund <and...@2ndquadrant.com> writes:
> On 2013-02-14 20:47:11 -0500, Tom Lane wrote:
>> Yeah, probably worth doing. At the time we thought that that code path
>> was just a short-term legacy thing for loading ancient pg_dump files.
>> However, given that even modern pg_dumps will use this syntax if
>> necessary to break circular dependencies for views, we're probably never
>> going to be rid of it completely.
> Yep, thats what I thought. Will write something up.
BTW, it strikes me that we *could* get pg_dump to stop doing this if we
wanted. Instead of the CREATE TABLE/CREATE RULE hack, we could have it
create a dummy view with the right rowtype like so:
CREATE VIEW v AS
SELECT null::typename1 AS colname1,
null::typename2 AS colname2, ... ;
then dump whatever had the circular-dependency issue with the view's
rowtype, and finally use CREATE OR REPLACE VIEW to replace the dummy
definition with the proper one.
This wouldn't really have any short-term benefit --- in particular, it
doesn't relieve the pressure to fix DefineQueryRewrite as you propose.
The advantage is that in ten years or so there would be no pg_dump files
anywhere using CREATE RULE "_RETURN", and so we could hope to eventually
deprecate that syntax. Which would let us get rid of the
RelIsBecomingView code path, and maybe have a bit more wiggle room to
remove or redesign the rule system.
That payoff is a little bit too far off to motivate me to do anything in
this line personally, but in case anybody else is more excited about it,
I thought I'd get the idea into the archives.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
