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
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 |