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.
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 |