Re: pg_dump --split patch
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Joel Jacobson <joel@gluefinance.com>
Cc: Gurjeet Singh <singh.gurjeet@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2010-12-28T21:57:34Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
pg_dump: Output functions deterministically sorted
- 7b583b20b1c9 9.3.0 cited
-
When sorting functions in pg_dump, break ties (same name) by number of arguments
- 1acc06a1f4ae 9.0.0 cited
On 12/28/2010 04:44 PM, Joel Jacobson wrote: > > > > >> The problem I see with suffixing a sequence id to the objects with >> name collision is that one day the dump may name myfunc(int) as >> myfunc.sql and after an overloaded version is created, say >> myfunc(char, int), then the same myfunc(int) may be dumped in >> myfunc-2.sql, which again is non-deterministic. > > I agree, good point! > Perhaps abbreviations are to prefer, e.g., myfunc_i, myfunc_i_c, etc > to reduce the need of truncating filenames. > > > I think that's just horrible. Does the i stand for integer or inet? And it will get *really* ugly for type names with spaces in them ... cheers andrew