Patch applied, thanks.
---
Robert Haas wrote:
> > I had a deeper look at this now. The patch looks clean and applies without
> > any problems, regression tests passes. However, ATRewriteTables() has a
> > problem when adding
> I had a deeper look at this now. The patch looks clean and applies without
> any problems, regression tests passes. However, ATRewriteTables() has a
> problem when adding columns with domains and constraints. Consider this
> small test case:
>
> CREATE TABLE bar (id INTEGER);
> CREATE OR REPLACE
> I had a deeper look at this now. The patch looks clean and applies without
> any problems, regression tests passes. However, ATRewriteTables() has a
> problem when adding columns with domains and constraints. Consider this
> small test case:
>
> CREATE TABLE bar (id INTEGER);
> CREATE OR REPLACE
--On Donnerstag, August 07, 2008 08:03:52 -0400 Robert Haas
<[EMAIL PROTECTED]> wrote:
Here's a patch that allows CREATE OR REPLACE VIEW to add new columns
to an existing view.
Any feedback would be appreciated, especially if it meant that I could
fix any problems before the next commitfest.
I'm just getting back around to this now. I guess I'm wondering if
someone could advise me on the best way of getting closer to a
committable patch.
The original patch just allows additional columns to be appended to
the previous column list (while disallowing all other sorts of
changes, includin
Zeugswetter Andreas OSB sIT <[EMAIL PROTECTED]> writes:
>> If you accept the idea that column identity should be based on column
>> name, then the only two operations that are really necessary are
>> "CREATE OR REPLACE VIEW" and "ALTER VIEW RENAME COLUMN", and it is
>> 100% clear what the semantics
> If you accept the idea that column identity should be based on column
> name, then the only two operations that are really necessary are
> "CREATE OR REPLACE VIEW" and "ALTER VIEW RENAME COLUMN", and it is
> 100% clear what the semantics of those operations should be.
+1
I think this would be
ALTER VIEW does not sound useful for me.
CREATE OR REPLACE VIEW should create or replace view and only thing that
should be same is the name of the view. It's up to Postgres to invalidate
all plans and up to developer to make sure that all places where his view is
used will stay still working. All
> Well, my feeling is that if we are inventing a new feature we ought not
> paint ourselves into a corner by failing to consider what will happen
> when obvious extensions to the feature are attempted. Whether the
> present patch is self-consistent is not the question --- the question
> is do we h
"Robert Haas" <[EMAIL PROTECTED]> writes:
> On Thu, Aug 7, 2008 at 5:26 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Because it sidesteps the problem of tracking which column is supposed to
>> be which. If you try to do it through CREATE OR REPLACE VIEW, you have
>> to either be extremely restrictiv
Forgot to copy my response to this to the list.
On Thu, Aug 7, 2008 at 5:26 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Robert Haas" <[EMAIL PROTECTED]> writes:
>> Although several people have said that they prefer the idea of using
>> ALTER VIEW to make changes to views, no one has really expanded
"Robert Haas" <[EMAIL PROTECTED]> writes:
> Although several people have said that they prefer the idea of using
> ALTER VIEW to make changes to views, no one has really expanded on the
> reasons for their preference.
Because it sidesteps the problem of tracking which column is supposed to
be whic
> I'm not too familiar with the syntax "a AS a(x, y)" but I think it's
> asking that the first two columns of a (whatever they are at the
> moment) be aliased to x and y.
Another possible option would be to introduce a syntax along the lines of
table AS table_alias (column AS column_alias, column
>> I think the only thing we need to agree on is that no future implementation
>> of CREATE OR REPLACE VIEW will ever implicitly rename a column. If we agree
>> on column name as a measure of column identity, then the change I'm
>> proposing is forward-compatible with any other enhancements we may
On Aug 7, 2008, at 13:01, Tom Lane wrote:
+1, although what does the standard say?
AFAICT the standard doesn't have any way to alter the definition of an
existing view at all. It might be worth asking what other systems do,
though --- can you alter a view in Oracle or DB2 or mysql?
Looks li
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> On Aug 7, 2008, at 08:43, Tom Lane wrote:
>> Maybe the right way is to *not* use CREATE OR REPLACE VIEW, but
>> rather ALTER VIEW ADD COLUMN and so on. Then column identity seems
>> a lot easier to keep track of.
> +1, although what does the standa
> Maybe the right way is to *not* use CREATE OR REPLACE VIEW, but
> rather ALTER VIEW ADD COLUMN and so on. Then column identity seems
> a lot easier to keep track of.
>
I prefere ALTER VIEW too
regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
"Robert Haas" <[EMAIL PROTECTED]> writes:
> I think the only thing we need to agree on is that no future implementation
> of CREATE OR REPLACE VIEW will ever implicitly rename a column. If we agree
> on column name as a measure of column identity, then the change I'm
> proposing is forward-compati
>> I was thinking that the ADD COLUMN should specify the new result list
>> entry.
>
> Yeah, that's what I was thinking too. If you needed to change more
> than just the topmost SELECT list, you'd need two steps: an ADD COLUMN
> and then CREATE OR REPLACE VIEW to change the query in some way that
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Andrew Dunstan escribió:
>> Tom Lane wrote:
>>> Maybe the right way is to *not* use CREATE OR REPLACE VIEW, but
>>> rather ALTER VIEW ADD COLUMN and so on. Then column identity seems
>>> a lot easier to keep track of.
>>
>> How would that look? Where w
Andrew Dunstan escribió:
>
>
> Tom Lane wrote:
>> Maybe the right way is to *not* use CREATE OR REPLACE VIEW, but
>> rather ALTER VIEW ADD COLUMN and so on. Then column identity seems
>> a lot easier to keep track of.
>
> How would that look? Where would we put the new query?
I was thinking that
> Hmm, maybe we need to pull off the project to separate logical attribute
> number from physical and position. It sounds like it could make it
> easier for view modification.
Much easier! It would be a nice feature to have for table as well.
Right now, if you have a table with columns (foo1, fo
Tom Lane wrote:
Maybe the right way is to *not* use CREATE OR REPLACE VIEW, but
rather ALTER VIEW ADD COLUMN and so on. Then column identity seems
a lot easier to keep track of.
How would that look? Where would we put the new query?
cheers
andrew
--
Sent via pgsql-hackers mailing lis
> But it seems hard to tell the difference between a "rename" and a
> "drop". I think that we aren't going to get far on this until we
> decide what we will consider to be the identity of a view column.
> With regular tables the attnum is a persistent identifier, but that
> doesn't seem to play ni
On Aug 7, 2008, at 08:43, Tom Lane wrote:
Maybe the right way is to *not* use CREATE OR REPLACE VIEW, but
rather ALTER VIEW ADD COLUMN and so on. Then column identity seems
a lot easier to keep track of.
+1, although what does the standard say?
Best,
David
--
Sent via pgsql-hackers mailing
Tom Lane escribió:
> But it seems hard to tell the difference between a "rename" and a
> "drop". I think that we aren't going to get far on this until we
> decide what we will consider to be the identity of a view column.
> With regular tables the attnum is a persistent identifier, but that
> doe
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Robert Haas escribió:
>> Here's a patch that allows CREATE OR REPLACE VIEW to add new columns
>> to an existing view.
> What happens with the columns previously defined? What happens if I
> specify a different column definition for them; does it raise
On Thu, Aug 7, 2008 at 11:17 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Robert Haas escribió:
>> Here's a patch that allows CREATE OR REPLACE VIEW to add new columns
>> to an existing view.
>>
>> Any feedback would be appreciated, especially if it meant that I could
>> fix any problems before
Robert Haas escribió:
> Here's a patch that allows CREATE OR REPLACE VIEW to add new columns
> to an existing view.
>
> Any feedback would be appreciated, especially if it meant that I could
> fix any problems before the next commitfest.
What happens with the columns previously defined? What hap
Here's a patch that allows CREATE OR REPLACE VIEW to add new columns
to an existing view.
Any feedback would be appreciated, especially if it meant that I could
fix any problems before the next commitfest.
Thanks,
...Robert
Index: doc/src/sgml/ref/create_view.sgml
===
30 matches
Mail list logo
