Re: Truncation of identifiers
| От | Gavin Flower |
|---|---|
| Тема | Re: Truncation of identifiers |
| Дата | |
| Msg-id | 5696F514.6000607@archidevsys.co.nz обсуждение исходный текст |
| Ответ на | Re: Truncation of identifiers (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On 14/01/16 13:05, Tom Lane wrote: > Thomas Munro <thomas.munro@enterprisedb.com> writes: >> Wouldn't it be better to raise an error when identifiers are too long, >> rather than accepting but truncating them? > I wouldn't think so. > >> I'm not aware of any other database that does this. > It's standard practice in most programming languages AFAIK. And SQL is > surely a programming language. > >> If you're using oversized identifiers you >> could finish up using more than one way to refer to the same database >> object, and then your queries will have a different meaning if >> NAMEDATALEN ever changes. > No, they'd just start failing if they didn't match the object (which > there can be only one of, else you'd have gotten other errors). > > Another argument against comes from the fact that NAMEDATALEN is usually > less than what SQL says is the minimum required length (viz, 128 > characters). Your proposal would have us throwing entirely needless > errors on queries that are fully spec-conformant. > > regards, tom lane > > I would prefer a database to be more strict. How about a GUC to control this behaviour, with the default to be lax? Cheers, Gavin
В списке pgsql-hackers по дате отправления: