Steve Atkins <steve@blighty.com> writes:
> I've also seen it with winzip. Again, ISTR that the exact limits were
> obscure but that restricting the path to less than 100 characters
> avoided any problems.
Hmm. It strikes me that the names seen by tar include "postgresql-x.y.z/".
The only file paths that approach 100 characters on that basis as of
8.4.1 are
postgresql-8.4.1/src/backend/utils/mb/conversion_procs/utf8_and_shift_jis_2004/utf8_and_shift_jis_2004.c
postgresql-8.4.1/src/backend/utils/mb/conversion_procs/utf8_and_euc_jis_2004/utf8_and_euc_jis_2004.c
postgresql-8.4.1/src/backend/utils/mb/conversion_procs/euc_jis_2004_and_shift_jis_2004/euc_jis_2004_and_shift_jis_2004.c
The first and third of these have in fact been reported as trouble
spots. AFAIR the second has not, but it's exactly 100 characters, which
would explain why it works ... or will work till we get to two digits in
the minor release number, anyway :-(. So that seems to validate your
theory.
If we want to set an upper limit of 100 characters, and allow for
release numbers up to 99.99.99, then the maximum length for
conversion_procs file names would be 19 characters (plus .c), and the
same for their directories. So we could rename these to, say,
utf8_and_sjis2004
utf8_and_euc2004
euc2004_sjis2004
This would be an easy change to make going forward (other than loss of
CVS history, but I'm not terribly worried about that for these files).
We could not so easily back-patch it because the .so filenames are
already embedded in installations' pg_proc tables. Personally I'd
be satisfied if it's fixed for 8.5 and beyond --- comments?
regards, tom lane