Re: Do we need use more meaningful variables to replace 0 in catalog head files?

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Hao Lee <mixtrue(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Do we need use more meaningful variables to replace 0 in catalog head files?
Date: 2016-11-11 07:17:32
Message-ID: CADkLM=cyFGExworYz5W8d7KXtNV_HsE1TUxC=UfWC6s5gvWPNQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 10, 2016 at 6:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2016-11-11 07:39:47 Re: Floating point comparison inconsistencies of the geometric types
Previous Message Ashutosh Bapat 2016-11-11 07:09:35 Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan.