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
