Re: trim() spec
От | Richard Poole |
---|---|
Тема | Re: trim() spec |
Дата | |
Msg-id | 20000613162550.C12354@office.vi.net обсуждение исходный текст |
Ответ на | Re: trim() spec (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Jun 13, 2000 at 10:45:07AM -0400, Tom Lane wrote: > Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > >> If trim(trailing 'abc' from '123cbabc') returns "123cb", current > >> trim() spec is broken. However, the spec that 'abc' means ~'[abc]' > >> is ugly. It seems that this ugly spec isn't used for any kind of > >> functions argument and SQL expression except for trim(). > > > afaict, the SQL92 spec for trim() requires a single character as the > > first argument; allowing a character string is a Postgres extension. On > > the surface, istm that this extension is in the spirit of the SQL92 > > spec, in that it allows trimming several possible characters. > > MySQL's crashme list has some useful information about this: they > indicate whether an implementation considers a multi-char TRIM argument > to be a set (our way) or a substring (MySQL does it that way, for one). > So there's precedent for both sides. > > Given that our trim() code claims to exist for Oracle compatibility, > I'd have assumed that its handling of multi-char arguments followed > Oracle. But the crashme list doesn't show Oracle as supporting either > semantics. Can someone with access to Oracle check this? Oracle 8i gives you an error if you give a multi-character argument to TRIM. So anything that worked with Oracle would work the same with us. Richard
В списке pgsql-hackers по дате отправления: