Just a suggestion: use an printably-encoded version of
md5 or sha, which are cryptographic hash algorithms.
It will make the name completely predictable:
if(too_long(name)) {name = md5(name);
}
It will be *very* unlikely that there are any collisions.
Of course, a person won't say "gee, party_address_relation_code_types_seq is
too
long, I guess that will turn out to be d4420a3105e98e3e2e12c5c73019db59".
> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Thomas Lockhart
> Sent: Wednesday, June 02, 1999 12:26 AM
> To: Tom Lane
> Cc: pgsql-hackers@postgreSQL.org; Zalman Stern
> Subject: Re: [HACKERS] Re: [SQL] Column name's length
>
>
> > How about something like this: if the code finds that the names are
> > too long when forming an implicit index name, it truncates the names
> > to fit, and you are OK as long as the truncated name is unique.
> > Comments? Objections? I think I could argue that this is a bug fix
> > and deserves to be slipped into 6.5 ;-)
>
> I understand some folks think this is a problem, but have been
> reluctant to include a "randomizer" in the created index name since it
> would make the index name less clearly predictable. May as well use
> something like "idx_<procid>_<timestamp>" or somesuch...
>
> No real objection though, other than aesthetics. And those only count
> for so much...
>
> - Tom
>
> --
> Thomas Lockhart lockhart@alumni.caltech.edu
> South Pasadena, California
>
>