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.

Reply via email to