Steve Atkins <steve@xxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
