From: | Richard Poole <richard(dot)poole(at)vi(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: trim() spec |
Date: | 2000-06-13 15:25:50 |
Message-ID: | 20000613162550.C12354@office.vi.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 13, 2000 at 10:45:07AM -0400, Tom Lane wrote:
> 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?
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-06-13 15:53:47 | Re: Big 7.1 open items |
Previous Message | Tom Lane | 2000-06-13 15:16:57 | Re: Big 7.1 open items |