Re: [SQL] text -> char - Mailing list pgsql-sql

From Tom Lane
Subject Re: [SQL] text -> char
Date
Msg-id 3855.951600426@sss.pgh.pa.us
Whole thread Raw
In response to text -> char  (Peter Stamfest <peter.stamfest@eunet.at>)
List pgsql-sql
Peter Stamfest <peter.stamfest@eunet.at> wrote a couple weeks ago:
> create view three as select CAST(substr(descr, 2, 4) as char(8)) as
> d from one;

That should work, and as of today it does work in current sources:

regression=# create view three as select CAST(substr(descr, 2, 4) as char(8))
regression-# as d from one;
CREATE 278003 1
regression=# \d three         View "three"Attribute |  Type   | Modifier
-----------+---------+----------d         | char(8) |
View definition: SELECT (substr(one.descr, 2, 4))::char(8) AS d FROM one;

Releases before 7.0 had a tendency to just discard casts :-( in a lot
of corner cases, and this is one of 'em.  I've cleaned up the cast
problems I know about, but there may be some left...

> The char() function works neither:
> create view four as select char(substr(descr, 2, 4)) as d from one;
> ERROR:  parser: parse error at or near "substr"

That's not a bug.  CHAR is an SQL reserved word for a type --- the
parser is expecting a type length indicator, like "char(8)", when it
sees CHAR(.

While there is a function named "char", you can only get at it by
double-quoting the name so it no longer looks like a keyword:

select "char"(substr(descr, 2, 4)) as d from one;

Also note that this converts to the internal single-byte char type,
which is presumably not what you wanted anyway.
        regards, tom lane


pgsql-sql by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: [SQL] New Optimizer Behaviour In 7.0b1
Next
From: Tom Lane
Date:
Subject: Re: [SQL] New Optimizer Behaviour In 7.0b1