Re: BUG #9541: Result of TRIM function has changed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: uehara(dot)kazuki(at)po(dot)ntts(dot)co(dot)jp
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #9541: Result of TRIM function has changed
Date: 2014-03-12 14:29:25
Message-ID: 11692.1394634565@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

uehara(dot)kazuki(at)po(dot)ntts(dot)co(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Yong Zhang 2014-03-12 14:52:03 Re: BUG #9531: Failed to install
Previous Message Joyce.Kai 2014-03-12 14:05:11 BUG #9548: jpg error 53 when trying to view jpg stored in blob field