Corey Huinker <corey.huin...@gmail.com> writes:
> On Wed, Nov 9, 2016 at 10:47 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Yeah, that's the thread I remembered. I think the basic conclusion was
>> that we needed a Perl script that would suck up a bunch of data from some
>> representation that's more edit-friendly than the DATA lines, expand
>> symbolic representations (regprocedure etc) into numeric OIDs, and write
>> out the .bki script from that. I thought some people had volunteered to
>> work on that, but we've seen no results ...
> If there are no barriers to adding it to our toolchain, could that
> more-edit-friendly representation be a SQLite database?
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.
(An example that's already there is FLOAT8PASSBYVAL for the value of
typbyval appropriate to float8 and allied types.)
I'm not very impressed with the suggestion of making a competing product
part of our build dependencies, either. 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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
