Re: autogenerating headers & bki stuff

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: autogenerating headers & bki stuff
Date: 2009-07-25 21:57:37
Message-ID: 407d949e0907251457x9318b28l415bc06605ca92a0@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jul 25, 2009 at 9:17 PM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
> Of course, fixing the Anum and
> Natts declarations does not come close to fixing this problem: for
> catalogs that are initialized with any data at bootstrap time, the
> DATA() lines are a much bigger issue, but fixing that is going to
> require a bigger hammer than can be put in place with one patch.  I do
> think this is a pretty good foundation on which to build, though.

I think addressing that would actually be fairly simple in theory.
Move a lot of those DATA lines to SQL initdb scripts. Virtually all of
pg_proc, pg_operator, pg_opclass, pg_opfamily, pg_cast, etc can be
initialized using SQL. Hardly any of the records in there are needed
for bootstrapping.

That would reduce the pain of editing this files *enormously*. The
worst part of adding new operators is making sure all the opclass
entries line up properly. And when there's an OID conflict and they
all have to be renumbered and the opclasses fixed up that's when
they're a real headache.

--
greg
http://mit.edu/~gsstark/resume.pdf

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-07-25 22:00:20 Re: Patch for 8.5, transformationHook
Previous Message Robert Haas 2009-07-25 21:51:12 Re: visibility maps and heap_prune