Re: BUG #9541: Result of TRIM function has changed - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #9541: Result of TRIM function has changed
Date
Msg-id 11692.1394634565@sss.pgh.pa.us
Whole thread Raw
In response to BUG #9541: Result of TRIM function has changed  (uehara.kazuki@po.ntts.co.jp)
Responses Re: BUG #9541: Result of TRIM function has changed  (上原 一樹 <uehara.kazuki@po.ntts.co.jp>)
List pgsql-bugs
uehara.kazuki@po.ntts.co.jp writes:
> Depending on the version, the result of the TRIM function is different.

I'm not sure that anyone would consider this a supported thing to do:

> CREATE FUNCTION LTRIM(CHAR,text)
> RETURNS text
> AS 'ltrim'
> LANGUAGE internal
> STRICT;

My attitude towards overriding system functions like that is "if it
breaks, you get to keep both pieces".  (BTW, is there a reason you
omitted IMMUTABLE from this?)

However,

> PostgreSQL9.3.3:
> | postgres=# SELECT '|' || TRIM(LEADING 'a' FROM 'abcd'::char(7)) || '|';
> |  ?column?
> | ----------
> |  |bcd   |
> | (1 row)

I get "|bcd|" from this example, in both 9.3 and HEAD branch.  I would
be surprised to get anything different, because the grammar converts
that syntax into "pg_catalog.ltrim(..., ...)" and so your override
function cannot be selected as the expansion.  At least not if the
override function went into schema "public", which would be the default.

I suspect that in 9.3.3 you forced the function into the pg_catalog
schema, but omitted to do that in the other two examples.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: postgres 8.2.13 compatibility with RHEL 6.4
Next
From: Rainer Tammer
Date:
Subject: Re: BUG #9547: Unable install postgres on AIX 5.3