From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Stamfest <peter(dot)stamfest(at)eunet(dot)at> |
Cc: | pgsql-sql(at)postgreSQL(dot)org |
Subject: | Re: [SQL] text -> char |
Date: | 2000-02-26 21:27:06 |
Message-ID: | 3855.951600426@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Peter Stamfest <peter(dot)stamfest(at)eunet(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-02-26 23:14:49 | Re: [SQL] New Optimizer Behaviour In 7.0b1 |
Previous Message | Mark Kirkwood | 2000-02-26 20:23:44 | Re: [SQL] New Optimizer Behaviour In 7.0b1 |