On Thu, Nov 10, 2016 at 6:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> I think you've fundamentally missed the point here. A data dump from a > table would be semantically indistinguishable from the lots-o-DATA-lines > representation we have now. What we want is something that isn't that. > In particular I don't see how that would let us have any extra level of > abstraction that's not present in the finished form of the catalog tables. > I was thinking several tables, with the central table having column values which we find semantically descriptive, and having lookup tables to map those semantically descriptive keys to the value we actually want in the pg_proc column. It'd be a tradeoff of macros for entries in lookup tables. > I'm not very impressed with the suggestion of making a competing product > part of our build dependencies, either. > I don't see the products as competing, nor did the presenter of https://www.pgcon.org/2014/schedule/events/736.en.html (title: SQLite: Protégé of PostgreSQL). That talk made the case that SQLite's goal is to be the foundation of file formats, not an RDBMS. I do understand wanting to minimize build dependencies. > If we wanted to get into build > dependency circularities, we could consider using a PG database in this > way ... but I prefer to leave such headaches to compiler authors for whom > it comes with the territory. > Agreed, bootstrapping builds aren't fun. This suggestion was a way to have a self-contained format that uses concepts (joining a central table to lookup tables) already well understood in our community.
