Re: Converting plpgsql to use DTYPE_REC for named composite types

2018-02-13 Thread Tom Lane
Pavel Stehule writes: > 2017-12-30 0:16 GMT+01:00 Tom Lane : >>> 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

Re: Converting plpgsql to use DTYPE_REC for named composite types

2018-01-24 Thread Tom Lane
Here's a version of this rebased up to HEAD, fixing a couple of trivial merge conflicts and incorporating the docs delta I posted separately. (I'd supposed this patch was still OK because the patch tester said so, but I now see that the tester was only testing the docs delta :-(.)

Re: Converting plpgsql to use DTYPE_REC for named composite types

2017-12-30 Thread Pavel Stehule
2017-12-30 0:16 GMT+01:00 Tom Lane : > 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 plpg

Re: Converting plpgsql to use DTYPE_REC for named composite types

2017-12-29 Thread Tom Lane
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 p

Re: Converting plpgsql to use DTYPE_REC for named composite types

2017-12-29 Thread Tom Lane
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 hacke

Re: Converting plpgsql to use DTYPE_REC for named composite types

2017-12-29 Thread Pavel Stehule
2017-12-29 18:38 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > Interesting part from test: > > > alter table mutable drop column f1; > > alter table mutable add column f1 float8; > > -- currently, this fails due to cached plan for "r.f1 + 1" expression > > select sillyaddone(42); > > ERROR: t

Re: Converting plpgsql to use DTYPE_REC for named composite types

2017-12-29 Thread Tom Lane
Pavel Stehule writes: > Interesting part from test: > alter table mutable drop column f1; > alter table mutable add column f1 float8; > -- currently, this fails due to cached plan for "r.f1 + 1" expression > select sillyaddone(42); > ERROR: type of parameter 4 (double precision) does not match t

Re: Converting plpgsql to use DTYPE_REC for named composite types

2017-12-29 Thread Pavel Stehule
Hi 2017-12-29 9:56 GMT+01:00 Pavel Stehule : > Hi > > 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 plpg

Re: Converting plpgsql to use DTYPE_REC for named composite types

2017-12-29 Thread Pavel Stehule
Hi 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 didn't ch

Converting plpgsql to use DTYPE_REC for named composite types

2017-12-27 Thread Tom Lane
Those with long memories will recall that for some time now I've been arguing that plpgsql should be changed to treat all composite-type variables (both "record" and named composite types) via its DTYPE_REC code paths, instead of the current situation where it handles variables of named composite t