Re: WIP: a way forward on bootstrap data - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: a way forward on bootstrap data
Date
Msg-id 30451.1522509923@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: a way forward on bootstrap data  (John Naylor <jcnaylor@gmail.com>)
Responses Re: WIP: a way forward on bootstrap data  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
John Naylor <jcnaylor@gmail.com> writes:
> And in the department of second thoughts, it occurred to me that the
> only reason that the .dat files are in include/catalog is because
> that's where the DATA() statements were. Since they are separate now,
> one could make the case that they actually belong in backend/catalog.
> One trivial advantage here is that there is already an existing
> Makefile in which to put convenience targets for formatting. On the
> other hand, it kind of makes sense to have the files describing the
> schema (.h) and the contents (.dat) in the same directory. I'm
> inclined to leave things as they are for that reason.

Yeah.  The fact that, eg, both the .h and .dat files are inputs to
duplicate_oids and unused_oids makes me think it's better to keep
them together.

I'd actually been thinking of something that's about the reverse:
instead of building the derived .h files in backend/catalog and
then symlinking them into include/catalog, it'd be saner to build
them in include/catalog to begin with.  However, that would mean
that the Perl scripts need to produce output in two different
places, so maybe it'd end up more complicated not less so.
In any case, that seems like something to leave for another day.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Isaac Morland
Date:
Subject: Re: csv format for psql
Next
From: Tomas Vondra
Date:
Subject: Re: Online enabling of checksums