On Sep 16, 2011, at 11:11 AM, Tom Lane wrote:

> "Caleb Welton" <caleb.wel...@emc.com> writes:
>> statements such as:
>>  PREPARE p1(anyelement) AS SELECT quote_literal($1);
>>  PREPARE p2(internal) AS SELECT int2recv($1);
>> Should not be allowed.
> 
> Hmm.  It would require an extra catalog lookup per parameter to enforce
> that.  Not sure that it's worth it just to prevent "peculiar" errors.
> Can you point to any worse consequences?
> 
>                       regards, tom lane


I haven't found any more severe issues and I'll agree its not a high priority 
item.  But the fix is simple enough that I don't see a reason to ignore it 
either.

The easiest fix would be, as you say, adding one extra syscache lookup:

static Query *
transformPrepareStmt(ParseState *pstate, PrepareStmt *stmt)
{
...
                foreach(l, stmt->argtypes)
                {
                        TypeName   *tn = lfirst(l);
                        Oid                     toid = typenameTypeId(pstate, 
tn);

        >               /* Pseudotypes are not valid parameters to PREPARE */
        >               if (get_typtype(toid) == TYPTYPE_PSEUDO)
        >               {
        >                       ereport(ERROR,
        >                                       
(errcode(ERRCODE_INDETERMINATE_DATATYPE),
        >                                        errmsg("type \"%s\" is not a 
valid parameter for PREPARE",
        >                                                       
TypeNameToString(tn))));
        >               }

                        argtoids[i++] = toid;
                }
...
}


If you really don't like the extra syscache lookup I'd offer two alternative 
implementations:

1) Creating a new macro IsPseudoType() like the existing IsPolymorphicType() 
macro given that we already have the oid.
2) TypenameGetTypid already has the whole cache tuple which contains both the 
pieces of information we want, but it only returns the oid... easy enough to 
fix, but larger api impact.

Regards,
  Caleb



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Reply via email to