From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | bhirt(at)mobygames(dot)com, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Numeric with '-' |
Date: | 2000-02-23 05:12:31 |
Message-ID: | 965.951282751@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> Remember that constants of random types like "line segment" have to
>> start out as character literals
> A constant of type line segment looks like this:
> LSEG 'whatever'
> This is an obvious extension of the standard. (Also note that this is
> *not* a cast.)
Yes it is. On what grounds would you assert that it isn't? Certainly
not on the basis of what comes out of gram.y; all three of these
produce exactly the same parsetree:
LSEG 'whatever'
'whatever'::LSEG
CAST('whatever' AS LSEG)
> It seems that for the benefit of a small crowd -- those actually using
> geometric types and being too lazy to type their literals in the above
> manner -- we are creating all sorts of problems for two much larger
> crowds
Au contraire. The real issue here is how to decide which numeric type
to use for an undecorated but numeric-looking literal token. I don't
think that's a non-mainstream problem, and I definitely don't think
that telling the odd-datatype crowd to take a hike will help fix it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Roberto Cornacchia | 2000-02-23 05:40:43 | about 7.0 LIMIT optimization |
Previous Message | Lincoln Yeoh | 2000-02-23 03:50:26 | Re: [GENERAL] TRANSACTIONS |