From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <janwieck(at)yahoo(dot)com> |
Cc: | Richard Emberson <emberson(at)phc(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: %ROWTYPE as PL/pgsql argument |
Date: | 2002-04-02 22:13:33 |
Message-ID: | 28182.1017785613@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jan Wieck <janwieck(at)yahoo(dot)com> writes:
> it doesn't work. Actually, giving just a relname as 'some-
> row-type' crashes the backend. Will take a look at it
> tomorrow.
I already did. It looks like plpgsql is mistakenly treating the type
as a scalar type (eg, using oidin/oidout to convert it ... which after
all is what pg_type says to do). The callee then crashes because it's
expecting a pointer to a tuple, and isn't getting one. Probably the
right fix is to implicitly assume %ROWTYPE behavior if we see that a
variable's type is marked typtype = 'c' in pg_type.
Meanwhile, passing a rowtype variable to a function doesn't work either.
The initial problem is that the reference to the rowtype variable never
gets replaced by an expression parameter reference, because
read_sql_construct() doesn't do anything with T_RECORD or T_ROW items;
I dunno if there are more problems beyond that one. (There are a lot
of other places that treat T_VARIABLE but not T_RECORD or T_ROW, too;
probably all of them need to be looked at.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bradley McLean | 2002-04-02 22:46:15 | Re: Suggestions please: names for function cachability attributes |
Previous Message | David Walker | 2002-04-02 22:09:14 | Re: Suggestions please: names for function cachability attributes |