Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> What I had been phantasizing about is an initdb completely in C that
> a) eliminates all shell incompatibilities
> b) doesn't depend on the grace of external utilities
These apparent advantages won't really be realized unless you propose
to replace *all* our shell-scripts with C; so I'm not persuaded by those
arguments. However
> c) doesn't need any external files
> The implemenation idea behind c) was to include all the catalog/*.h files
> directly, having changed the DATA() and DESC() macros prior, thus
> eliminating the need for .bki files, genbki.sh (which fortunately hadn't
> had any compatibility problems), another set of files being installed that
> you don't really need at runtime.
is very attractive indeed --- it'd eliminate the risk of incompatibility
between genbki's interpretation of the catalog .h files and the C
compiler's interpretation thereof, as well as give us more flexibility
in what we put in the .h files. (For example, I just finished hacking
up genbki.sh to interpret "INDEX_MAX_KEYS*2" and "INDEX_MAX_KEYS*4"
correctly. If we ever go to 8-byte oids, that code will need fixed
again. Whole problem goes away if the tables are processed by the C
compiler...)
What I'd be inclined to think about is a compromise: leave initdb as
mostly a shell script, but replace genbki.sh and the lib template files
with something that compiles up tables equivalent to the template files
and when invoked spits out bootstrapping commands on its stdout. It'd
be very easy to test: diff its output against the existing template files.
> Also you wouldn't need pg_version or pg_encoding which implies you don't
> need libpq, which means you don't need to set LD_LIBRARY_PATH.
Again, not very interesting, since you won't get far until you have
made libpq.so accessible...
regards, tom lane
