On Wed, Dec 2, 2020 at 10:18 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > On Wed, Dec 02, 2020 at 11:52:54AM -0500, Tom Lane wrote: > > Dmitry Dolgov <9erthali...@gmail.com> writes: > > >> On Mon, Nov 30, 2020 at 02:26:19PM +0100, Dmitry Dolgov wrote: > > >>> On Mon, Nov 30, 2020 at 04:12:29PM +0300, Alexander Korotkov wrote: > > >>> The idea of an opaque field in SubscriptingRef structure is more > > >>> attractive to me. Could you please implement it? > > > > >> Sure, doesn't seem to be that much work. > > > > I just happened to notice this bit. This idea is a complete nonstarter. > > You cannot have an "opaque" field in a parsetree node, because then the > > backend/nodes code has no idea what to do with it for > > copy/compare/outfuncs/readfuncs. The patch seems to be of the opinion > > that "do nothing" is adequate, which it completely isn't. > > > > Perhaps this is a good juncture at which to remind people that parse > > tree nodes are read-only so far as the executor is concerned, so > > storing something there only at execution time won't work either. > > Oh, right, stupid of me. Then I'll just stick with the original > Alexanders suggestion.
Stupid me too :) I didn't get we can't add opaque field to SubscriptingRefState without adding it to SubscriptingRef, which has to support copy/compare/outfuncs/readfuncs ------ Regards, Alexander Korotkov
