I wrote:
> Martijn van Oosterhout writes:
>> In this particular case the syntax makes it unclear that the substring
>> is the problem. Perhaps here the solution would be to put a cast in the
>> grammer, like so:
> ...
> But I think we could do this in substr_list in the case where we have
> just "
In article <[EMAIL PROTECTED]>,
Martijn van Oosterhout writes:
> It's even sillier than that:
> test=# SELECT substring ('1234567890' FOR 4::bigint);
> substring
> ---
> (1 row)
> test=# SELECT substring ('1234567890' FOR 4::int);
> substring
> ---
> 1234
> (1 row)
> Look
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Fri, 11 Nov 2005, Tom Lane wrote:
>> I was toying with the idea of making it translate instead to
>>
>> pg_catalog.substring(foo, 1, (bar)::int4)
>>
>> since AFAICS there isn't any other reasonable mapping once you have
>> committed to having the "1"
On Fri, 11 Nov 2005, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > It looks to me like we should be supporting any exact numeric with scale 0
> > there (at least AFAICS from SQL92 and SQL03), so I don't think the current
> > behavior is compliant. It doesn't look like adding a nu
Martijn van Oosterhout writes:
> In this particular case the syntax makes it unclear that the substring
> is the problem. Perhaps here the solution would be to put a cast in the
> grammer, like so:
> substr_for: FOR a_expr { $$ =3D
> makeTypeCast($2,"int4"); }
>
Stephan Szabo <[EMAIL PROTECTED]> writes:
> It looks to me like we should be supporting any exact numeric with scale 0
> there (at least AFAICS from SQL92 and SQL03), so I don't think the current
> behavior is compliant. It doesn't look like adding a numeric overload
> of the function works, and th
On Fri, Nov 11, 2005 at 07:47:12AM -0800, Stephan Szabo wrote:
>
> On Fri, 11 Nov 2005, Tom Lane wrote:
> > This has been complained of before. The problem is that there is no
> > implicit cast from bigint to int, but there is one from bigint to text,
> > so the only acceptable mapping the parser
On Fri, 11 Nov 2005, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > It's even sillier than that:
>
> > test=# SELECT substring ('1234567890' FOR 4::bigint);
> > substring
> > ---
> >
> > (1 row)
>
> > test=# SELECT substring ('1234567890' FOR 4::int);
> > substring
> > --
Martijn van Oosterhout writes:
> It's even sillier than that:
> test=# SELECT substring ('1234567890' FOR 4::bigint);
> substring
> ---
>
> (1 row)
> test=# SELECT substring ('1234567890' FOR 4::int);
> substring
> ---
> 1234
> (1 row)
This has been complained of before.
It's even sillier than that:
test=# SELECT substring ('1234567890' FOR 4::bigint);
substring
---
(1 row)
test=# SELECT substring ('1234567890' FOR 4::int);
substring
---
1234
(1 row)
Looking at the explain verbose make it look like it's using the wrong
version of substring
Consider the following:
CREATE TEMP TABLE tbl (
id SERIAL NOT NULL,
PRIMARY KEY (id)
);
COPY tbl (id) FROM stdin;
1
2
3
4
\.
SELECT substring ('1234567890' FOR (SELECT count (*) FROM tbl)::int);
This returns '1234', as expected. But
SELECT substring ('1234567890' F
11 matches
Mail list logo
