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 VIEW
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 VIEW
--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,
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
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 an
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 of those
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
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 happens
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 the next
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 an
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
doesn't
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
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 nicely for
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
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,
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 the ADD
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 would we put the
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
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-compatible
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
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 standard say?
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
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 want to
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 AS
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 which. If
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 on the
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 restrictive (like
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 have
30 matches
Mail list logo
