Sean Chittenden <sean@chittenden.org> writes:
> The first part I knew, but the historical behavior mentioned is
> interesting... I haven't run into a naming conflict yet, but will
> probably change things to preemptively thwart such problems. This
> oddity seems pretty unknown and certainly not something I recall having
> read about... what are the odds that this will be changed in the
> future? Low, very low, never, or someday if there's time/effort?
It is documented, see "33.4.2. SQL Functions on Composite Types"
about halfway down this page:
http://www.postgresql.org/docs/7.4/static/xfunc-sql.html#AEN28791
I'm not really inclined to rip it out unless we get complaints, which
AFAIR there have been hardly any of. One could argue that this is a
useful feature, since it essentially allows you to build columns that
are computed on-the-fly from other columns. I believe some other DBMSes
tout such things as features ;-)
> It's clearly a complex problem to have the rewrite engine handle this
> correctly in that I don't know how the database could resolve the NEW
> pseudorelational for an insert into v1 as a table rowtype for t1.
Well, it wouldn't; you'd need to declare the function parameter as v1's
rowtype not t1's. RECORD might be handy as a means of only having to
write one function for several similar problems --- it'd be exactly a
polymorphic-function facility. But it's not essential.
What we do need is a cleaner way of handling whole-row variables inside
the execution engine. The present coding is crufty, restrictive, and
leaks memory :-(.
What would also be needed to solve the particular problem you are
hitting is a "row constructor" runtime construct, comparable to the
ARRAY[] construct that Joe Conway created recently for arrays. Then
the rule rewriter could expand an insert rule's "NEW.*" into a ROW[]
construct with the actual expressions from the rewritten query inside.
The SQL spec has something sort of like this in its VALUES() construct,
but it doesn't allow for associating a particular named type with the
row, which means it's not quite what we need.
regards, tom lane
