From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michel Pelletier <pelletier.michel@gmail.com>
cc: Pavel Stehule <pavel.stehule@gmail.com>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: Using Expanded Objects other than Arrays from plpgsql
In-reply-to: <CACxu=vKMWjj+XJ0=Ok9iZmTwUfRXytVsdv8+U5X4LMUPTM5iiw@mail.gmail.com>
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> <CACxu=vK+S6BXN8ZYyBvqQBWrcwHXqtue1-ZuKO3+XtHGBYcDUQ@mail.gmail.com> <CAFj8pRCd6xcH-AYEyHFdGdU89O9JjZ-v-pyQnOwd9zNJkCEdhQ@mail.gmail.com> <3797606.1732045516@sss.pgh.pa.us> <CACxu=!
 vKMWjj+XJ0=Ok9iZmTwUfRXytVsdv8+U5X4LMUPTM5iiw@mail.gmail.com>
Comments: In-reply-to Michel Pelletier <pelletier.michel@gmail.com>
	message dated "Sat, 04 Jan 2025 08:37:39 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <647218.1736019347.1@sss.pgh.pa.us>
Date: Sat, 04 Jan 2025 14:35:47 -0500
Message-ID: <647219.1736019347@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/647219.1736019347%40sss.pgh.pa.us>
Precedence: bulk

Michel Pelletier <pelletier.michel@gmail.com> writes:
> I've circled back on this task to do some work improving the skeleton code,
> but going back through our thread I landed on this point Tom made about
> usefulness vs pure skeleton and my natural desire is to make a simple
> expanded object that is also useful, so I brainstormed a bit and decided to
> try something relatively simple but also (IMO) quite useful, an expanded
> datum that wraps sqlite's serialize/derserialize API:
> https://github.com/michelp/postgres-sqlite

I think the odds that we'd accept a module with a dependency on sqlite
are negligible.  It's too big of a build dependency for too little
return.  Also, I'm sure that a module defined like that would be a
pretty poor example/starting point for other expanded-object
applications: there'd be too many aspects that have only to do with
interfacing to sqlite, making it hard to see the expanded-object
forest for the sqlite trees.

I have to admit though that the forest-v-trees aspect makes it fairly
hard to think of any suitable example module that would serve much
real-world purpose.  Likely scenarios for expanded objects just have
a lot of functionality in them.  For instance, I thought for a moment
of suggesting that teaching contrib/hstore to work with expanded
representations of hstores could be useful.  But I'd forgotten how
much functionality that type has.  It'd be a big project and would
still have a lot of baggage.

			regards, tom lane