Gregory Stark wrote:
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.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster