Re: Using Expanded Objects other than Arrays from plpgsql

On Sat, Jan 4, 2025 at 11:35 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Michel Pelletier <pelletier(dot)michel(at)gmail(dot)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.

That's fair, I wasn't sure if contrib modules could have optional build
dependencies that just skip building that module if they are not
installed. If this were the case for users who want to study the approach
they can look at the code, and users who want to use the feature can
install the dependency or maybe require a configuration flag like
--with-sqlite.

> 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 don't agree it would be a poor example, there are really only two touch
points with sqlite that matter, the call to sqlite3_serialize in the
flattening function and sqlite3_deserialize in the expander and consist of
a simple pointer exchange and memcpy. That code is in its own file,
separate from the exec/query/dump code which can be effectively ignored by
someone looking to understand the expansion life cycle.

> 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.

Agree that an expanded object is only useful if it provides functionality.
My original pgexpanded extension from way back provided a dumb dense matrix
to do matrix multiplication, but I trimmed it out to just be the counter as
posted earlier in this thread, and you in turn mentioned maybe it should
just be a malloc'ed string, but in either case the pointlessness of it
bothers me a bit so I was hoping to find something that just crosses the
line into useful while still being a really simply expanded example.

-Michel