Re: Converting plpgsql to use DTYPE_REC for named composite types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Converting plpgsql to use DTYPE_REC for named composite types
Date: 2017-12-30 03:39:05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I wrote:
> I hacked on the domain-support problem a bit and it worked out well,
> so attached is a revised patch that incorporates that. This caused
> me to revise some assumptions about what expandedrecord.c's internal
> invariants ought to be, so it's probably better to look at this as
> a new patch rather than a diff from v1.

Oh, I'd not looked at the documentation angle of this. Here's a short
add-on patch which just adds the fact that "record" is now a valid
argument type, and removes a no-longer-correct claim that system columns
are always inaccessible in row variables.

The documentation draws a distinction between "record" and "row" variables
which is now rather artificial so far as the code is concerned. But it's
not totally pointless either, since it's still true that a variable
declared "record" will mutate its type in a way that a
named-composite-type variable will not. I'm inclined to leave that text
as is; anyone think differently?

regards, tom lane

Attachment Content-Type Size
use-dtype-rec-docs.patch text/x-diff 1.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-12-30 03:47:30 CONSTANT/NOT NULL/initializer properties for plpgsql record variables
Previous Message Sergey Burladyan 2017-12-30 01:30:07 Re: Why standby restores some WALs many times from archive?