Re: Resolution for "ERROR: cannot handle whole-row reference" ?

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

In response to

Browse pgsql-general by date

  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