From: | Scott Royston <scroyston71(at)yahoo(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Implicit cast of literal in SQL statements |
Date: | 2001-12-27 20:37:14 |
Message-ID: | 830E7B29-FB09-11D5-92C0-000393577144@yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
I've seen a few postings in multiple newsgroups saying that in 7.1.x and
up, literals in SQL statements are implicitly cast to strings.
For example in:
select distinct 'hello' from mytable;
the 'hello' is implicitly assumed to be 'hello'::text
However, in both 7.1.3, and a fresh build of 7.2b4 from cvs, (with all
regressions passing) I get:
mytest=# select distinct 'hello' from mytable;
ERROR: Unable to identify an ordering operator '<' for type 'unknown'
Use an explicit ordering operator or modify the query
an explicit 'hello'::text works fine.
I've spent a day looking through the code and can't really find any
obvious #define's or compile time flags that would be causing this
problem.
It looks like
Const *
make_const(Value *value)
{
...
case T_String:
val = DirectFunctionCall1(textin,
CStringGetDatum(strVal(value)));
typeid = UNKNOWNOID; /* will be coerced
later */
typelen = -1; /* variable len */
typebyval = false;
break;
...
}
does the damage, and it never gets 'coerced later', at least not before
transformDistinctClause(...) gets called, which is where the failure
happens (a few levels down).
does this really work for everybody else? Can someone point me to a
compile flag I may be missing, or the code that actually does the
implicit cast?
thanks
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-27 21:22:56 | Re: Implicit cast of literal in SQL statements |
Previous Message | Tom Lane | 2001-12-27 14:49:50 | Re: Serializable access giving wrong error messages? |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavlo Baron | 2001-12-27 20:37:40 | Re: patch: INSERT INTO t VALUES (a, b, ..., DEFAULT, ...) |
Previous Message | Pavlo Baron | 2001-12-27 16:19:51 | Re: patch: INSERT INTO t VALUES (a, b, ..., DEFAULT, ...) |