|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Re: Converting plpgsql to use DTYPE_REC for named composite types|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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
|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?|