Re: trim() spec

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: SAKAIDA Masaaki <sakaida(at)psn(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: trim() spec
Date: 2000-06-13 14:45:07
Message-ID: 3784.960907507@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-06-13 14:50:41 Re: Big 7.1 open items
Previous Message Tom Lane 2000-06-13 14:36:24 Re: Re: setproctitle