Added to TODO:
* Improve ability to modify views via ALTER TABLE
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00691.php
---
Robert Haas wrote:
> I think the real problem here is that P
Merlin Moncure wrote:
On Wed, May 21, 2008 at 4:39 AM, Andreas Pflug
<[EMAIL PROTECTED]> wrote:
Not the whole reason. To get a view definition that is more readable, the
pretty_bool option of pg_get_viewdef already does some newline and indent
formatting. Not the initial formatting, but Good Eno
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Yeah. The current restrictions were set when CREATE OR REPLACE VIEW
>> was first implemented, and at that time we didn't have very much
>> ALTER TABLE capability at all; the view restrictions mirror what we
>> co
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Robert Haas" <[EMAIL PROTECTED]> writes:
>> I think the real problem here is that PostgreSQL is very finicky about
>> what operations you can perform on a view. If I have a table foo and
>> I define a view bar that uses foo and a view baz that uses bar, I
"Robert Haas" <[EMAIL PROTECTED]> writes:
> I think the real problem here is that PostgreSQL is very finicky about
> what operations you can perform on a view. If I have a table foo and
> I define a view bar that uses foo and a view baz that uses bar, I can
> add a column to foo without a problem,
I think the real problem here is that PostgreSQL is very finicky about
what operations you can perform on a view. If I have a table foo and
I define a view bar that uses foo and a view baz that uses bar, I can
add a column to foo without a problem, and, similarly, I can also drop
or alter a column
On Wed, May 21, 2008 at 7:56 AM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-05-21 at 10:40 +0200, Andreas Pflug wrote:
>> Florian Pflug wrote:
>> >
>> > But maybe you could store the whitespace appearing before (or after?)
>> > a token in the parse tree that is stored for a view. That
On Wed, 2008-05-21 at 10:40 +0200, Andreas Pflug wrote:
> Florian Pflug wrote:
> >
> > But maybe you could store the whitespace appearing before (or after?)
> > a token in the parse tree that is stored for a view. That might not
> > allow reconstructing the *precise* statement, but at least the
On Wed, May 21, 2008 at 4:39 AM, Andreas Pflug
<[EMAIL PROTECTED]> wrote:
> Not the whole reason. To get a view definition that is more readable, the
> pretty_bool option of pg_get_viewdef already does some newline and indent
> formatting. Not the initial formatting, but Good Enough (TM), I believe
Florian Pflug wrote:
But maybe you could store the whitespace appearing before (or after?)
a token in the parse tree that is stored for a view. That might not
allow reconstructing the *precise* statement, but at least the
reconstructed statement would preserve newlines and indention - which
David Fetter wrote:
On Tue, May 20, 2008 at 02:03:17PM -0400, Merlin Moncure wrote:
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:
+1 for DDL in general, including the or
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I wonder if there is any merit to the idea of storing the 'create
> view' statement that created the view in an appropriate place.
No, there isn't.
As counterexamples look at pg_constraint.consrc and pg_attrdef.adsrc,
both of which were mistakes from
On Tue, May 20, 2008 at 02:03:17PM -0400, Merlin Moncure wrote:
> 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:
+1 for DDL in general, including the original CREATE and
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.
14 matches
Mail list logo
