Gregory Stark wrote:
[snip]
>
> Hm. The set of output columns could change? How?
>
> If you prepare "select *" and add a column, you're saying the query should
> start failing? That seems strange given the behaviour of views, which is that
> once parsed the list of columns is written in stone. It seems prepared queries
> should work the same way that views work and remember which physical column
> they were referring to previously. (Personally I don't like that behaviour but
> it feels like this should be consistent with it.)
>
> I guess you do have a serious problem if you redefine the type of a column or
> redefine a view (though I think you would have to drop and recreate it, CREATE
> OR REPLACE wouldn't let you change the output columns).
>
I would think it best to move towards changing views to not have output
columns set in stone. It seems unreasonable that you can add/drop/alter
columns in a table as much as you like, but you can't touch a view. I
also not excited about the current view restrictions. Which means we
don't want to start backing the idea by putting in more code that acts
in the same way.
I'm guessing from what Tom is saying, that the reason we have views set
in stone is because they are/can be an example of inlined SQL.
Particularly when views are built on views. Any further enlightenment
welcome, but probably off topic for this thread.
Russell Smith
