MIME-Version: 1.0
References: <CACxu=vJaKFNsYxooSnW1wEgsAO5u_v1XYBacfVJ14wgJV_PYeg@mail.gmail.com>
 <1342498.1729444411@sss.pgh.pa.us> <CACxu=vLXvpzN4X3k+9jsMt6ujuOvFVUSkA80t_cROSsF4y2jQQ@mail.gmail.com>
 <1445998.1729482404@sss.pgh.pa.us> <CACxu=vKEF8Qa-OaADFxf0uMg-xw6gH_CNCWd2s+xaqh-gY4=xg@mail.gmail.com>
 <2062830.1729625620@sss.pgh.pa.us> <2265411.1729699470@sss.pgh.pa.us>
 <CACxu=v++HNmss59yGUDkRny7g=M8tZ2YXF07AUXqKVGqcSfxGQ@mail.gmail.com>
 <2354718.1729737539@sss.pgh.pa.us> <2581216.1729794746@sss.pgh.pa.us>
 <CACxu=v+dn37zr8gx5xNP-EZY3OLtGLTHrbx_ZkCQc40HpyMLKA@mail.gmail.com>
 <1948345.1730500073@sss.pgh.pa.us> <CACxu=vL7i_U_iSNpREe8eCAMEyKHuPpk9THRpBhk+ar0U1EdOw@mail.gmail.com>
 <CACxu=vKLc6f5N8_DR58LKkE1eohWSxTvThTeGsLm7p7QH1aFBA@mail.gmail.com> <CACxu=vJf2S=ysun_h=zmYNu6oUM47+egbpX5mMC0X9BJK=EQwQ@mail.gmail.com>
In-Reply-To: <CACxu=vJf2S=ysun_h=zmYNu6oUM47+egbpX5mMC0X9BJK=EQwQ@mail.gmail.com>
From: Michel Pelletier <pelletier.michel@gmail.com>
Date: Tue, 19 Nov 2024 09:50:29 -0800
Message-ID: <CACxu=vK+S6BXN8ZYyBvqQBWrcwHXqtue1-ZuKO3+XtHGBYcDUQ@mail.gmail.com>
Subject: Re: Using Expanded Objects other than Arrays from plpgsql
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000006f3bf9062747adbb"
Archived-At: <https://www.postgresql.org/message-id/CACxu%3DvK%2BS6BXN8ZYyBvqQBWrcwHXqtue1-ZuKO3%2BXtHGBYcDUQ%40mail.gmail.com>
Precedence: bulk

--0000000000006f3bf9062747adbb
Content-Type: text/plain; charset="UTF-8"

>
>
> So going back on the assumption I'm somehow not returning the right
> pointer, but digging into the array code I'm pretty sure I'm following the
> same pattern and tracing my code path is calling EOHPGetRWDatum when I
> return the object, I can't get it to stop on DeleteExpandedObject, so I
> don't think plpgsql is deleting it, I'm going to keep investigating, sorry
> for the noise.
>

A couple years ago I tried to compress what I learned about expanded
objects into a dummy extension that just provides the necessary
boilerplate.  It wasn't great but a start:

https://github.com/michelp/pgexpanded

Pavel Stehule indicated this might be a good example to put into contrib:

https://www.postgresql.org/message-id/CAFj8pRDnAnsm8pMosEys-TDRZpnCx1KaxePjV8HT6A1JPQtsCw@mail.gmail.com

I've updated the repo to include points from our current discussion wrt
multiple expansions in a plpgsql function, and added some test functions.
The new pgexpanded type just keeps track of the number of times it's been
expanded starting from an initialized value.  While it only stores a
flattened integer, it follows the typical pattern of pallocing the value
and pfreeing it with a memory context callback, so it should be covering
most of the boilerplate needed to start a new expanded type.

This would also be a good place to showcase and test the support function
feature you've described to me.

It occurs to me that including this example in contrib would be an easier
way for us to collaborate on my existing issue instead of punting back and
forth on the list and would benefit all future expanded object developers.
Do you think that's a good idea?  If this were in contrib you could access
the code I'm working with directly and I can just follow along in my
project.

-Michel

--0000000000006f3bf9062747adbb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><div>So=
 going back on the assumption I&#39;m somehow not returning the right point=
er, but digging into the array code I&#39;m pretty sure I&#39;m following t=
he same pattern and tracing my code path is calling EOHPGetRWDatum when I r=
eturn the object, I can&#39;t get it to stop on DeleteExpandedObject, so I =
don&#39;t think plpgsql is deleting it, I&#39;m going to keep investigating=
, sorry for the noise.</div></div></div></blockquote><div><br></div>A coupl=
e years ago I tried to compress what I learned about expanded objects into =
a dummy extension that just provides the necessary boilerplate.=C2=A0 It wa=
sn&#39;t great but a start:<div><br></div><div><a href=3D"https://github.co=
m/michelp/pgexpanded">https://github.com/michelp/pgexpanded</a></div><div><=
br></div><div>Pavel Stehule indicated this might be a good example to put i=
nto contrib:</div><div><br></div><div><a href=3D"https://www.postgresql.org=
/message-id/CAFj8pRDnAnsm8pMosEys-TDRZpnCx1KaxePjV8HT6A1JPQtsCw@mail.gmail.=
com">https://www.postgresql.org/message-id/CAFj8pRDnAnsm8pMosEys-TDRZpnCx1K=
axePjV8HT6A1JPQtsCw@mail.gmail.com</a></div><br class=3D"gmail-Apple-interc=
hange-newline"><div>I&#39;ve updated the repo to include points from our cu=
rrent discussion wrt multiple expansions in a plpgsql function, and added s=
ome test functions.=C2=A0 The new pgexpanded type just keeps track of the n=
umber of times it&#39;s been expanded starting from an initialized value.=
=C2=A0 While it only stores a flattened integer, it follows the typical pat=
tern of pallocing the value and pfreeing it with a memory context callback,=
 so it should be covering most of the boilerplate needed to start a new exp=
anded type.</div><div><br></div><div>This would also be a good place to sho=
wcase and test the support function feature you&#39;ve described to me.</di=
v><div><br></div><div>It occurs to me that including this example in contri=
b would be an easier way for us to collaborate on my existing issue instead=
 of punting back and forth on the list and would benefit all future expande=
d object developers.=C2=A0 Do you think that&#39;s a good idea?=C2=A0 If th=
is were in contrib you could access the code I&#39;m working with directly =
and I can just follow along in my project.</div><div><br></div><div>-Michel=
</div></div></div>

--0000000000006f3bf9062747adbb--