inferred param types for PREPARE - Mailing list pgsql-patches

From Neil Conway
Subject inferred param types for PREPARE
Date
Msg-id 1137312217.9145.41.camel@localhost.localdomain
Whole thread Raw
Responses Re: inferred param types for PREPARE  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Attached is a patch that makes the specification of parameters to the
PREPARE SQL statement more flexible: the user can specify "unknown" to
have the type of a particular parameter inferred from the context in
which the parameter is used (if possible). If fewer parameter types are
specified than the number of parameters used in the query, the remaining
parameter types will be inferred in the same way. This is analogous to
the way that parameters can be specified and inferred for protocol-level
prepared statements.

The only trickiness was allowing "UNKNOWN" to be specified in the list
of type names in the PREPARE statement. Since UNKNOWN was previously an
unreserved_keyword, this caused reduce/reduce conflicts:

state 1186

  788 prep_type_elem: UNKNOWN .
  1477 unreserved_keyword: UNKNOWN .

    ')'       reduce using rule 788 (prep_type_elem)
    ')'       [reduce using rule 1477 (unreserved_keyword)]
    ','       reduce using rule 788 (prep_type_elem)
    ','       [reduce using rule 1477 (unreserved_keyword)]
    $default  reduce using rule 1477 (unreserved_keyword)

I promoted UNKNOWN to be a col_name_keyword (like most of the other
builtin type names), which solved the problem. If there is a better fix,
let me know (I won't claim to be a yacc expert).

This is just a quick and dirty patch; if no one objects to this feature,
tomorrow I will post a revised patch that includes updates to the
documentation and regression tests.

-Neil


Attachment

pgsql-patches by date:

Previous
From: Neil Conway
Date:
Subject: Re: TupleDesc refcounting
Next
From: Tom Lane
Date:
Subject: Re: TupleDesc refcounting