Re: [PATCHES] inferred param types for PREPARE

2006-01-15 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] writes:
 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:

You're doing it wrong.  There is no need for any special case whatever
in gram.y --- ordinary lookup of the type name will do fine.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [PATCHES] inferred param types for PREPARE

2006-01-15 Thread Neil Conway
On Sun, 2006-01-15 at 12:17 -0500, Tom Lane wrote:
 You're doing it wrong.  There is no need for any special case whatever
 in gram.y --- ordinary lookup of the type name will do fine.

Woops, good point. Attached is a revised patch that doesn't modify the
grammar, and includes updates to the documentation and regression tests.
Applied to HEAD.

-Neil


*** doc/src/sgml/ref/deallocate.sgml	47093d8fa4ee9a32c2913ea147d3d9502a51a12e
--- doc/src/sgml/ref/deallocate.sgml	a9b19cf7cc5471f6cbd52c015eeb3fa24b57821d
***
*** 25,31 
  
   refsynopsisdiv
  synopsis
! DEALLOCATE [ PREPARE ] replaceable class=parameterplan_name/replaceable
  /synopsis
   /refsynopsisdiv
  
--- 25,31 
  
   refsynopsisdiv
  synopsis
! DEALLOCATE [ PREPARE ] replaceable class=parametername/replaceable
  /synopsis
   /refsynopsisdiv
  
***
*** 58,64 
 /varlistentry
  
 varlistentry
! termreplaceable class=parameterplan_name/replaceable/term
  listitem
   para
The name of the prepared statement to deallocate.
--- 58,64 
 /varlistentry
  
 varlistentry
! termreplaceable class=parametername/replaceable/term
  listitem
   para
The name of the prepared statement to deallocate.

*** doc/src/sgml/ref/execute.sgml	fa053d68c10cadae226e45da2c38199325043346
--- doc/src/sgml/ref/execute.sgml	12d45d714aeaf6494d6c3b12e995c980626f9099
***
*** 25,31 
  
   refsynopsisdiv
  synopsis
! EXECUTE replaceable class=PARAMETERplan_name/replaceable [ (replaceable class=PARAMETERparameter/replaceable [, ...] ) ]
  /synopsis
   /refsynopsisdiv
  
--- 25,31 
  
   refsynopsisdiv
  synopsis
! EXECUTE replaceable class=PARAMETERname/replaceable [ (replaceable class=PARAMETERparameter/replaceable [, ...] ) ]
  /synopsis
   /refsynopsisdiv
  
***
*** 60,66 
  
variablelist
 varlistentry
! termreplaceable class=PARAMETERplan_name/replaceable/term
  listitem
   para
The name of the prepared statement to execute.
--- 60,66 
  
variablelist
 varlistentry
! termreplaceable class=PARAMETERname/replaceable/term
  listitem
   para
The name of the prepared statement to execute.
***
*** 73,82 
  listitem
   para
The actual value of a parameter to the prepared statement.  This
!   must be an expression yielding a value of a type compatible with
!   the data type specified for this parameter position in the
!   commandPREPARE/command command that created the prepared
!   statement.
   /para
  /listitem
 /varlistentry
--- 73,81 
  listitem
   para
The actual value of a parameter to the prepared statement.  This
!   must be an expression yielding a value that is compatible with
!   the data type of this parameter, as was determined when the
!   prepared statement was created.
   /para
  /listitem
 /varlistentry

*** doc/src/sgml/ref/prepare.sgml	3449586c977e47e193388d8c2fa4ff250b06e59f
--- doc/src/sgml/ref/prepare.sgml	d54a7b2167a1c5a83fe305ad97b1d1bc270c92c9
***
*** 25,31 
  
   refsynopsisdiv
  synopsis
! PREPARE replaceable class=PARAMETERplan_name/replaceable [ (replaceable class=PARAMETERdatatype/replaceable [, ...] ) ] AS replaceable class=PARAMETERstatement/replaceable
  /synopsis
   /refsynopsisdiv
  
--- 25,31 
  
   refsynopsisdiv
  synopsis
! PREPARE replaceable class=PARAMETERname/replaceable [ (replaceable class=PARAMETERdatatype/replaceable [, ...] ) ] AS replaceable class=PARAMETERstatement/replaceable
  /synopsis
   /refsynopsisdiv
  
***
*** 45,57 
  
para
 Prepared statements can take parameters: values that are
!substituted into the statement when it is executed. To include
!parameters in a prepared statement, supply a list of data types in
!the commandPREPARE/command statement, and, in the statement to
!be prepared itself, refer to the parameters by position using
!literal$1/literal, literal$2/literal, etc. When executing
!the statement, specify the actual values for these parameters in
!the commandEXECUTE/command statement.  Refer to xref
 linkend=sql-execute endterm=sql-execute-title for more
 information about that.
/para
--- 45,59 
  
para
 Prepared statements can take parameters: values that are
!substituted into the statement when it is executed. When creating
!the prepared statement, refer to parameters by position, using
!literal$1/, literal$2/, etc. A corresponding list of
!parameter data types can optionally be specified. When a
!parameter's data type is not specified or is declared as
!literalunknown/literal, the type is inferred from the context
!in which the 

Re: [PATCHES] inferred param types for PREPARE

2006-01-15 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] writes:
 Woops, good point. Attached is a revised patch that doesn't modify the
 grammar, and includes updates to the documentation and regression tests.

BTW, I wonder whether it wouldn't be a better idea to declare the
pg_prepared_statement view's parameter_types column as regtype[]
instead of oid[].  This would make the default output much more
readable, ie you'd get things like '{integer,boolean}' instead of
'{23,16}'.  Of course you can cast in either direction to get the
other form, but defaulting to text instead of numeric output seems
like it might be a better choice.

The option of casting to get the other form should probably be mentioned
in the view's documentation page, whichever is the default.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [PATCHES] inferred param types for PREPARE

2006-01-15 Thread Neil Conway
On Sun, 2006-01-15 at 17:33 -0500, Tom Lane wrote:
 BTW, I wonder whether it wouldn't be a better idea to declare the
 pg_prepared_statement view's parameter_types column as regtype[]
 instead of oid[].

Yeah, good point -- I had thought that using type names would be
ambiguous in the presence of schemas, but of course regtype solves that
problem. Attached is a patch that implements this -- barring any
objections I'll apply this tomorrow.

-Neil


*** doc/src/sgml/catalogs.sgml	324ea64622e513dbf036e56cc38f4ccc2955ef6e
--- doc/src/sgml/catalogs.sgml	156840ca28113a4e95833cd9b5c5d410e047c366
***
*** 284,291 
entry
 The initial value of the transition state.  This is a text
 field containing the initial value in its external string
!representation.  If this field is null, the transition state
!value starts out null.
/entry
   /row
  /tbody
--- 284,291 
entry
 The initial value of the transition state.  This is a text
 field containing the initial value in its external string
!representation.  If this field is NULL, the transition state
!value starts out NULL.
/entry
   /row
  /tbody
***
*** 293,302 
/table
  
para
!New aggregate functions are registered with the commandCREATE
!AGGREGATE/command command.  See xref linkend=xaggr for more
!information about writing aggregate functions and the meaning of
!the transition functions, etc.
/para
  
   /sect1
--- 293,303 
/table
  
para
!New aggregate functions are registered with the xref
!linkend=sql-createaggregate endterm=sql-createaggregate-title
!command.  See xref linkend=xaggr for more information about
!writing aggregate functions and the meaning of the transition
!functions, etc.
/para
  
   /sect1
***
*** 1018,1024 
entrytypebool/type/entry
entry/entry
entry
!Role may log in, that is, this role can be given as the initial
 session authorization identifier.
/entry
   /row
--- 1019,1025 
entrytypebool/type/entry
entry/entry
entry
!Role may log in. That is, this role can be given as the initial
 session authorization identifier.
/entry
   /row
***
*** 1561,1567 
entrystructfieldrelukeys/structfield/entry
entrytypeint2/type/entry
entry/entry
!   entryunused  (emphasisnot/emphasis the number of unique keys)/entry
   /row
  
   row
--- 1562,1568 
entrystructfieldrelukeys/structfield/entry
entrytypeint2/type/entry
entry/entry
!   entryUnused  (emphasisnot/emphasis the number of unique keys)/entry
   /row
  
   row
***
*** 1568,1574 
entrystructfieldrelfkeys/structfield/entry
entrytypeint2/type/entry
entry/entry
!   entryunused  (emphasisnot/emphasis the number of foreign keys on the table)/entry
   /row
  
   row
--- 1569,1575 
entrystructfieldrelfkeys/structfield/entry
entrytypeint2/type/entry
entry/entry
!   entryUnused  (emphasisnot/emphasis the number of foreign keys on the table)/entry
   /row
  
   row
***
*** 1575,1581 
entrystructfieldrelrefs/structfield/entry
entrytypeint2/type/entry
entry/entry
!   entryunused/entry
   /row
  
   row
--- 1576,1582 
entrystructfieldrelrefs/structfield/entry
entrytypeint2/type/entry
entry/entry
!   entryUnused/entry
   /row
  
   row
***
*** 1583,1589 
entrytypebool/type/entry
entry/entry
entry
!True if we generate an OID for each row of the relation.
/entry
   /row
  
--- 1584,1590 
entrytypebool/type/entry
entry/entry
entry
!True if we generate an OID for each row of the relation
/entry
   /row
  
***
*** 1592,1598 
entrytypebool/type/entry
entry/entry
entry
!True if the table has (or once had) a primary key.
/entry
   /row
  
--- 1593,1599 
entrytypebool/type/entry
entry/entry
entry
!True if the table has (or once had) a primary key
/entry
   /row
  
***
*** 1601,1607 
entrytypebool/type/entry
entry/entry
entryTrue if table has rules; see
!structnamepg_rewrite/structname catalog.
/entry
   /row
  
--- 1602,1608 
entrytypebool/type/entry
entry/entry
entryTrue if table has rules; see
!structnamepg_rewrite/structname catalog
/entry
   /row
  
***
*** 1609,1615 
entrystructfieldrelhassubclass/structfield/entry