Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> Tom Lane wrote:
>> Yeah, that would work. Quick-hack proof-of-concept patch attached.
> This is a rather ugly, but I guess not untenable. I suppose we don't
> care about any actual typmod, do we?.
We get the type and typmod both from the expression. Example:
regression=# create table ref (f1 varchar, f2 varchar(3));
CREATE TABLE
regression=# insert into ref values('1','2');
INSERT 0 1
regression=# select '1234567890'::type(f1) from ref;
type
------------
1234567890
(1 row)
regression=# select '1234567890'::type(f2) from ref;
type
------
123
(1 row)
> Will this be of any use with the
> PostGIS types and such, for which the typmod is not merely a size limit?
Don't see why not. They still have to follow the rule that typmod is a
static property of an expression.
> Also INTERVAL has some funny typmod rules, not sure if that affects
> usage of this construct.
I would not think so. The weirdness about INTERVAL mainly has to do with
SQL's, ahem, inventive collection of ways to write an interval constant,
and that wouldn't really be an issue for any practical use of this
construct AFAICS. Whatever you write as the expression, we're going to
be able to reduce to a type OID and typmod.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
