Re: BUG #3435: problem with substring function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
Cc: "Carlos Quintero" <carlos(dot)quintero(dot)sspa(at)juntadeandalucia(dot)es>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3435: problem with substring function
Date: 2007-07-10 14:16:01
Message-ID: 19104.1184076961@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
> It has little bit strange behave on 8.3. It works well, but I have to
> use casting.

> postgres=# select substring('1234' from to_number('3', '999999')::int for 3);
> substring
> -----------
> 34
> (1 row)

Yeah, the OP is getting burnt by an implicit cast to text, which the
parser picks because there is no implicit cast from numeric to integer
... but substring(text,text,text) has completely different behavior
from substring(text,int,int).

The reason we got rid of most implicit casts to text for 8.3 was exactly
to stop surprising choices like this one.

>> This is a sample, really i like to use an expression using date_part() as
>> the first parameter for substring.

There's no implicit cast from float8 to integer, either.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2007-07-10 14:26:18 Re: BUG #3436: inherited primary keys are not reported as primary key by the Java DatabaseMetaData
Previous Message FAGOT Alain 2007-07-10 12:14:12 BUG #3436: inherited primary keys are not reported as primary key by the Java DatabaseMetaData