Re: Converting plpgsql to use DTYPE_REC for named composite types

2017-12-30 0:16 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> I wrote:
> > I'll stick this into the January commitfest, but I'd like to get it
> > reviewed and committed pretty soon, because there are follow-on patches
> > that need to get done in time for v11 --- in particular, we need to close
> > out the lack of plpgsql support for domains-over-composite.
>
> 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.
>
> Mostly this is changes internal to expandedrecord.c, but I cleaned up
> some code in plpgsql that tests for domain-ness, and I also added support
> in ExecEvalFieldSelect for extracting a field directly from an expanded
> record without flattening it into a tuple first. It hadn't been clear
> that that was worth the trouble before, but it definitely does come up
> while applying domain constraints. For example, having that fast path
> makes about a 2X speed difference in a test like this:
>
> create type two_ints as (f1 int, f2 int);
> create domain ordered_ints as two_ints check((value).f1 <= (value).f2);
>
> \timing on
>
> do $$
> declare d ordered_ints;
> begin
> for i in 1..3000000 loop
> d.f2 := i;
> d.f1 := i;
> end loop;
> end$$;
>
>
> There are still a couple of soft spots having to do with enforcing
> domain constraints against null composite values, e.g. if there's
> a constraint that would reject a null value we don't notice that
> at DECLARE time. I think there's not much point in being strict
> about that until we have support for initializers for composite
> variables. Which is definitely worth doing but it seems like it
> could be a separate patch.
>
> The patches in <11986(dot)1514407114(at)sss(dot)pgh(dot)pa(dot)us> still apply over this
> with just some line-number offsets, so I won't post a new version
> of those.
>
>
all test passed on my comp too.

I think so these patches can be useful for schema variables too.

Regards

Pavel

> regards, tom lane
>
>