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