John Cochran <j69coch...@gmail.com> writes:
> My proposal is the have the following directory structure
> .../src/timezone - Would have only PostgreSQL specific code
> .../src/timezone/tznames - would be unaltered from current (optionally this
> could be removed)
> .../src/timezone/iana - would contain unaltered code and data from IANA
> The .../src/timezone/data directory would be removed.
I am not in favor of doing anything to the data/ directory. If we can
have unaltered tzcode source files in their own subdirectory, that'd be
great, but I see no advantage to smashing the IANA code and data files
together. Furthermore, doing so would break the existing ability to just
cherry-pick tzdata update commits into back branches.
Part of my thought here is that we do generally just dump tzdata updates
into our tree without much thought, but I don't think that will ever be
the case for tzcode updates; we'll want to look at those with more care,
and probably we'll not back-patch them.
> 1. I would have liked to recommend 2 sub-directories underneath
> .../src/timezone/iana named "code" and "data", but unfortunately have to
> suggest untarring both the code and data files directly into the iana
> directory. The reason for this is that the IANA code does not compile using
> the IANA Makefile unless the script yearistype.sh is present and that
> script is currently present in the data tar file, not the code tar file.
I have exactly zero expectation of using their Makefile, so this is not a
concern.
> 2. Depositing the IANA code unaltered would also deposit some "junk" files
> into the directory. The files would mainly consist of man pages and html
> files containing documentation for the timezone code. The extra files would
> consume approximately 500 kilobytes above what's actually needed, but
> otherwise wouldn't have any adverse effects.
We're not doing that either, IMO. Why should we invest 500K of tarball
space on that?
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
