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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
