| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Why no CONSTANT for row variables in plpgsql? |
| Date: | 2015-10-20 23:29:47 |
| Message-ID: | 20038.1445383787@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> writes:
> On 10/19/15 7:12 PM, Tom Lane wrote:
>> IMO, we ought to get rid of the use of that representation for
>> composite-type variables and use the RECORD code paths for them,
> That also means there would only need to be changes to RECORD to allow
> CONSTANT, default, etc.
> Do you know offhand what the starting point for changing that would be?
> build_datatype()?
Well, definitely build_datatype would want to select PLPGSQL_TTYPE_REC not
PLPGSQL_TTYPE_ROW when seeing TYPTYPE_COMPOSITE. I suspect that's just a
small tip of a large iceberg, though.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2015-10-21 00:05:40 | Re: Freeze avoidance of very large table. |
| Previous Message | Jim Nasby | 2015-10-20 22:53:54 | Re: Why no CONSTANT for row variables in plpgsql? |