I wrote:
> So I'm feeling that this may not be a good idea, or at least not a good
> implementation of the idea. I'm inclined to reject the patch rather than
> lock us into something that is not standard and doesn't really do what
> people would be likely to want.
BTW, a potentially workable fix to the problem of not wanting to lock
down column lists in stored rules is to create a syntax that represents
whole-row, record-oriented assignment directly. Then we need not be
concerned with individual columns at parse time at all. So imagine
something like this:
UPDATE dst SET * = new WHERE ...;
UPDATE dst SET * = (SELECT src FROM src WHERE ...);
or if you needed to construct a row value at runtime you could write
UPDATE dst SET * = ROW(x,y,z) WHERE ...;
UPDATE dst SET * = (SELECT ROW(x,y,z) FROM src WHERE ...);
The main bit of functionality that would be lost compared to the current
patch is the ability to use DEFAULT for some of the row members. But I am
not sure there is a compelling use-case for that: seems like if you have
some DEFAULTs in there then it's unlikely that you don't know the column
list accurately, so the existing (col1,col2,...) syntax will serve fine.
This seems like it might not be unduly complex to implement, although
it would have roughly nothing in common with the current patch.
If we were to go in this direction, it would be nice to at the same time
add a similar whole-record syntax for INSERT. I'm not sure exactly what
that should look like though. Also, again, we ought to be paying
attention to how this would match up with UPSERT syntax.
regards, tom lane
