* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Let me be clear here: I don't think we can or should ever make this
> into an error by default. Doing that would break spec-compliant
> applications, whether or not they are using names that actually have
> any conflicts.
If we increase the length to the spec requirement (full disclosure- I
havn't checked the spec on this myself), I'd be for making it an error
if someone goes over that limit. Right now we have a risk of spec
compliant applications not working under PG for nearly zero good
justification in today's age (iow- I don't really buy the concern about
the size, and if that is a reasonable concern then we could look at
putting in the effort to make it variable length and seriously reduce
today's wasted space).
Regarding the other concerns about how we don't honor the spec
completely- those are situations where we are more flexible and allow
more than the spec says we should. Those are not things which would
break a spec-compliant application, while this is.
> There's some possible value in having a non-default option to throw
> error for overlength names, but TBH I fear that it won't buy all that
> much, because people won't think to turn it on when testing.
I agree that it wouldn't make sense to have an option to make it an
error which is off by default.
> Given the historical volume of complaints (to wit, none up to now),
> I can't get very excited about changing the behavior here. I think
> we're more likely to annoy users than accomplish anything useful.
The lack of compliants is a good reason to not lose sleep over this, I
don't think it's an excuse which allows us to ignore the spec and
applications which adhere to it, if there's someone willing to do the
work to fix it.
I'm not volunteering (yet), but I wouldn't say "no, we're never going to
fix this" either. Perhaps a TODO item to investigate the value of
making relname variable length? Or to investigate the actual impact of
increasing the length?
Thanks,
Stephen
