Re: Converting plpgsql to use DTYPE_REC for named composite types

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.1514407114@sss.pgh.pa.us> still apply over this
with just some line-number offsets, so I won't post a new version
of those.

            regards, tom lane