public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Andrey Borodin <[email protected]>
Cc: Michel Pelletier <[email protected]>
Cc: Pavel Stehule <[email protected]>
Cc: [email protected]
Subject: Re: Using Expanded Objects other than Arrays from plpgsql
Date: Sun, 26 Jan 2025 14:04:41 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CACxu=vJaKFNsYxooSnW1wEgsAO5u_v1XYBacfVJ14wgJV_PYeg@mail.gmail.com>
<[email protected]>
<CACxu=vLXvpzN4X3k+9jsMt6ujuOvFVUSkA80t_cROSsF4y2jQQ@mail.gmail.com>
<[email protected]>
<CACxu=vKEF8Qa-OaADFxf0uMg-xw6gH_CNCWd2s+xaqh-gY4=xg@mail.gmail.com>
<[email protected]>
<[email protected]>
<CACxu=v++HNmss59yGUDkRny7g=M8tZ2YXF07AUXqKVGqcSfxGQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<CACxu=v+dn37zr8gx5xNP-EZY3OLtGLTHrbx_ZkCQc40HpyMLKA@mail.gmail.com>
<[email protected]>
<CACxu=vL7i_U_iSNpREe8eCAMEyKHuPpk9THRpBhk+ar0U1EdOw@mail.gmail.com>
<CACxu=vKLc6f5N8_DR58LKkE1eohWSxTvThTeGsLm7p7QH1aFBA@mail.gmail.com>
<CACxu=vJf2S=ysun_h=zmYNu6oUM47+egbpX5mMC0X9BJK=EQwQ@mail.gmail.com>
<CACxu=vK+S6BXN8ZYyBvqQBWrcwHXqtue1-ZuKO3+XtHGBYcDUQ@mail.gmail.com>
<CAFj8pRCd6xcH-AYEyHFdGdU89O9JjZ-v-pyQnOwd9zNJkCEdhQ@mail.gmail.com>
<[email protected]>
<647219! ! ! [email protected]>
<CACxu=vJ1UeXPjPOzfT2E=tFpSCxPxcB7hgfqHYmefJWh3ZXPew@mail.gmail.com>
<[email protected]>
<CACxu=vKModwqSpEjpn-ur1uMAEYkcd-i8CvNsH-z9=dk7F7YQw@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Andrey Borodin <[email protected]> writes:
> On 26 Jan 2025, at 20:37, Tom Lane <[email protected]> wrote:
>> Maybe we should recast it as an action. What do you think of
>> "mark_expr_as_assignment_source"?
> Sounds better to me. I found no examples of similar functions nether in pl_gram.y, nor in gram.y, so IMO mark_expr_as_assignment_source() is the best candidate.
WFM, I'll make it so in next version.
> Got it, many thanks for the explanation.
I'll see about incorporating more of that in the comments, too.
> I wonder if you plan similar optimizations for array_cat(), array_remove() etc?
> + a := a || a; -- not optimizable
> Why is it not optimizable? Because there is no support function, because array_cat() has no support function, or something else?
plpgsql won't attempt to optimize it because "a" is referenced twice
and there is no support function that might say it's safe anyway.
array_cat doesn't currently have any special smarts about expanded
arrays, so it's all moot because the arrays would get flattened
on the way into it. If we did improve it to be able to cope with
expanded arrays, I'm not real sure that it could safely manage an
in-place update where the two inputs are the same array --- at
the least, some extreme care would be needed to get the right
answers.
I'm not real excited about optimizing additional array operations
anyway. Maybe some more will get done at some point, but I don't
see that as part of this work.
regards, tom lane
view thread (34+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Using Expanded Objects other than Arrays from plpgsql
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox