From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Sean Chittenden <sean(at)chittenden(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Resolution for "ERROR: cannot handle whole-row reference" ? |
Date: | 2004-03-28 21:44:06 |
Message-ID: | 18818.1080510246@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Sean Chittenden <sean(at)chittenden(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Klint Gore | 2004-03-28 22:53:04 | bugs list working??? |
Previous Message | Carl E. McMillin | 2004-03-28 21:36:15 | Hacking postgres backend process |