Re: trim() spec

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: trim() spec
Дата
Msg-id 3784.960907507@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: trim() spec  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
Ответы Re: trim() spec  (Richard Poole <richard.poole@vi.net>)
Список pgsql-hackers
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?

> I'm not sure if SQL3/SQL99 has anything extra to say on this.

The 1994 draft specifies just a single trim character, same as SQL92.
Haven't gotten around to grabbing the 99 draft yet...
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: setproctitle
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Big 7.1 open items