Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group