Re: Postgres 7.3.5 and count('x')

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ramirez(at)idconcepts(dot)org (Edwin S(dot) Ramirez)
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Postgres 7.3.5 and count('x')
Date: 2003-12-15 22:33:33
Message-ID: 16505.1071527613@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I said:
> ramirez(at)idconcepts(dot)org (Edwin S. Ramirez) writes:
> [ "select count('x') from some_table" fails ]

> The most direct fix is probably to make any_in() return some random
> value (may as well be ((Datum) 0)) instead of producing an error.

After further investigation I have decided that this is really just an
issue of incorrect ordering of tests in parse_coerce.c. The attached
proposed patch arranges for the ANY/ANYELEMENT/ANYARRAY short-circuit
path to be taken before we check for UNKNOWN-type literals and Params.
The net effect is that coercion to ANY/ANYELEMENT/ANYARRAY will have
*no effect* on an UNKNOWN literal. This seems reasonable, since in
these contexts we don't really know any more than we did before about
the type of the literal; it's really still UNKNOWN.

One side effect besides fixing Edwin's gripe is that where before,

regression=# select 'x'::unknown::anyelement;
ERROR: cannot accept a value of type anyelement

now you get a result:

regression=# select 'x'::unknown::anyelement;
anyelement
------------
x
(1 row)

I think this is reasonable, since coercion of other objects besides
unknown literals to anyelement is a no-op:

regression=# select 'x'::text::anyelement;
anyelement
------------
x
(1 row)

regression=# select 2::anyelement;
anyelement
------------
2
(1 row)

Comments? Any objections to the patch?

regards, tom lane

*** src/backend/parser/parse_coerce.c~ Mon Dec 8 15:37:30 2003
--- src/backend/parser/parse_coerce.c Sat Dec 13 13:21:41 2003
***************
*** 153,158 ****
--- 153,166 ----
/* no conversion needed */
return node;
}
+ if (targetTypeId == ANYOID ||
+ targetTypeId == ANYARRAYOID ||
+ targetTypeId == ANYELEMENTOID)
+ {
+ /* assume can_coerce_type verified that implicit coercion is okay */
+ /* NB: we do NOT want a RelabelType here */
+ return node;
+ }
if (inputTypeId == UNKNOWNOID && IsA(node, Const))
{
/*
***************
*** 260,273 ****
param->paramtype = targetTypeId;
return (Node *) param;
}
- if (targetTypeId == ANYOID ||
- targetTypeId == ANYARRAYOID ||
- targetTypeId == ANYELEMENTOID)
- {
- /* assume can_coerce_type verified that implicit coercion is okay */
- /* NB: we do NOT want a RelabelType here */
- return node;
- }
if (find_coercion_pathway(targetTypeId, inputTypeId, ccontext,
&funcId))
{
--- 268,273 ----
***************
*** 372,388 ****
if (!typeidIsValid(targetTypeId))
return false;

- /*
- * If input is an untyped string constant, assume we can convert
- * it to anything except a class type.
- */
- if (inputTypeId == UNKNOWNOID)
- {
- if (ISCOMPLEX(targetTypeId))
- return false;
- continue;
- }
-
/* accept if target is ANY */
if (targetTypeId == ANYOID)
continue;
--- 372,377 ----
***************
*** 396,401 ****
--- 385,401 ----
}

/*
+ * If input is an untyped string constant, assume we can convert
+ * it to anything except a class type.
+ */
+ if (inputTypeId == UNKNOWNOID)
+ {
+ if (ISCOMPLEX(targetTypeId))
+ return false;
+ continue;
+ }
+
+ /*
* If pg_cast shows that we can coerce, accept. This test now
* covers both binary-compatible and coercion-function cases.
*/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-12-15 22:56:36 Re: Use of 'cp -r' in CREATE DATABASE
Previous Message Bruce Momjian 2003-12-15 22:28:41 7.4.1 release notes