From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "PG Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | idea: storing view source in system catalogs |
Date: | 2008-05-20 18:03:17 |
Message-ID: | b42b73150805201103v52b53a05rdd7029dce79d4c2c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wonder if there is any merit to the idea of storing the 'create
view' statement that created the view in an appropriate place. There
are basically two reasons for this:
*) preserve initial formatting, etc.
Database functions when viewed with \df+ in psql appear nice and clean
as I wrote them. Much better than \d <view>
*) store what the view intends to do, not what it does.
If I do:
create view v as select * from foo;
The view definition as understood by the database expands the column
list. This has unfortunately means that the view definition is no
longer valid if the underlying type changes. Understandably, select *
is often considered bad style but nevertheless often comes up when
writing 'advanced' type manipulation that postgresql is so good at.
This also comes up when expanding composite type for example.
The idea here is to provide a stepping stone towards allowing the view
to be redefined against source objects during invalidation events.
ISTM the easiest and best way to do that is to try and reapply the
original definition against the altered dependant objects and throw
the resultant error, if any. Views can be a real pain to deal with
than functions in terms of DDL operations.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Sam Mason | 2008-05-20 18:51:32 | Re: triggers on prepare, commit, rollback... ? |
Previous Message | Merlin Moncure | 2008-05-20 17:29:55 | Re: libpq object hooks (libpq events) |