Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.
Дата
Msg-id 18198.1485272795@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Assignment of valid collation for SET operations onqueries with UNKNOWN types.  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
I wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> The table of Pseudo-Types needs to be updated as well with unknown in
>> datatype.sgml.

> Check.

Here's an updated patch with doc changes.  Aside from that one,
I tried to spell "pseudo-type" consistently, and I changed one
place where we were calling something a pseudo-type that isn't.

            regards, tom lane

diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 3bc6854..9ef7b4a 100644
*** a/doc/src/sgml/datatype.sgml
--- b/doc/src/sgml/datatype.sgml
*************** SELECT * FROM pg_attribute
*** 4661,4666 ****
--- 4661,4670 ----
     </indexterm>

     <indexterm zone="datatype-pseudo">
+     <primary>unknown</primary>
+    </indexterm>
+
+    <indexterm zone="datatype-pseudo">
      <primary>opaque</primary>
     </indexterm>

*************** SELECT * FROM pg_attribute
*** 4782,4789 ****
         </row>

         <row>
          <entry><type>opaque</></entry>
!         <entry>An obsolete type name that formerly served all the above purposes.</entry>
         </row>
        </tbody>
       </tgroup>
--- 4786,4800 ----
         </row>

         <row>
+         <entry><type>unknown</></entry>
+         <entry>Identifies a not-yet-resolved type, e.g. of an undecorated
+          string literal.</entry>
+        </row>
+
+        <row>
          <entry><type>opaque</></entry>
!         <entry>An obsolete type name that formerly served many of the above
!          purposes.</entry>
         </row>
        </tbody>
       </tgroup>
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index d7117cb..aebe898 100644
*** a/doc/src/sgml/ddl.sgml
--- b/doc/src/sgml/ddl.sgml
*************** WHERE c.altitude > 500 AND c.tableoid
*** 2579,2585 ****

    <para>
     Another way to get the same effect is to use the <type>regclass</>
!    pseudo-type, which will print the table OID symbolically:

  <programlisting>
  SELECT c.tableoid::regclass, c.name, c.altitude
--- 2579,2585 ----

    <para>
     Another way to get the same effect is to use the <type>regclass</>
!    alias type, which will print the table OID symbolically:

  <programlisting>
  SELECT c.tableoid::regclass, c.name, c.altitude
diff --git a/doc/src/sgml/plhandler.sgml b/doc/src/sgml/plhandler.sgml
index 0fc5d7b..57a2a05 100644
*** a/doc/src/sgml/plhandler.sgml
--- b/doc/src/sgml/plhandler.sgml
***************
*** 26,32 ****
      language such as C, using the version-1 interface, and registered
      with <productname>PostgreSQL</productname> as taking no arguments
      and returning the type <type>language_handler</type>.  This
!     special pseudotype identifies the function as a call handler and
      prevents it from being called directly in SQL commands.
      For more details on C language calling conventions and dynamic loading,
      see <xref linkend="xfunc-c">.
--- 26,32 ----
      language such as C, using the version-1 interface, and registered
      with <productname>PostgreSQL</productname> as taking no arguments
      and returning the type <type>language_handler</type>.  This
!     special pseudo-type identifies the function as a call handler and
      prevents it from being called directly in SQL commands.
      For more details on C language calling conventions and dynamic loading,
      see <xref linkend="xfunc-c">.
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 5f89db5..e315548 100644
*** a/doc/src/sgml/protocol.sgml
--- b/doc/src/sgml/protocol.sgml
***************
*** 668,674 ****
       number of parameter symbols (<literal>$</><replaceable>n</>)
       used in the query string.  Another special case is that a parameter's
       type can be specified as <type>void</> (that is, the OID of the
!      <type>void</> pseudotype).  This is meant to allow parameter symbols
       to be used for function parameters that are actually OUT parameters.
       Ordinarily there is no context in which a <type>void</> parameter
       could be used, but if such a parameter symbol appears in a function's
--- 668,674 ----
       number of parameter symbols (<literal>$</><replaceable>n</>)
       used in the query string.  Another special case is that a parameter's
       type can be specified as <type>void</> (that is, the OID of the
!      <type>void</> pseudo-type).  This is meant to allow parameter symbols
       to be used for function parameters that are actually OUT parameters.
       Ordinarily there is no context in which a <type>void</> parameter
       could be used, but if such a parameter symbol appears in a function's
diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml
index ef623d5..30792f4 100644
*** a/doc/src/sgml/queries.sgml
--- b/doc/src/sgml/queries.sgml
*************** SELECT * FROM vw_getfoo;
*** 762,768 ****
       In some cases it is useful to define table functions that can
       return different column sets depending on how they are invoked.
       To support this, the table function can be declared as returning
!      the pseudotype <type>record</>.  When such a function is used in
       a query, the expected row structure must be specified in the
       query itself, so that the system can know how to parse and plan
       the query.  This syntax looks like:
--- 762,768 ----
       In some cases it is useful to define table functions that can
       return different column sets depending on how they are invoked.
       To support this, the table function can be declared as returning
!      the pseudo-type <type>record</>.  When such a function is used in
       a query, the expected row structure must be specified in the
       query itself, so that the system can know how to parse and plan
       the query.  This syntax looks like:
diff --git a/doc/src/sgml/ref/create_function.sgml b/doc/src/sgml/ref/create_function.sgml
index 8108a43..e705778 100644
*** a/doc/src/sgml/ref/create_function.sgml
--- b/doc/src/sgml/ref/create_function.sgml
*************** CREATE [ OR REPLACE ] FUNCTION
*** 160,167 ****
        </para>
        <para>
         Depending on the implementation language it might also be allowed
!        to specify <quote>pseudotypes</> such as <type>cstring</>.
!        Pseudotypes indicate that the actual argument type is either
         incompletely specified, or outside the set of ordinary SQL data types.
        </para>
        <para>
--- 160,167 ----
        </para>
        <para>
         Depending on the implementation language it might also be allowed
!        to specify <quote>pseudo-types</> such as <type>cstring</>.
!        Pseudo-types indicate that the actual argument type is either
         incompletely specified, or outside the set of ordinary SQL data types.
        </para>
        <para>
*************** CREATE [ OR REPLACE ] FUNCTION
*** 199,205 ****
         can be a base, composite, or domain type,
         or can reference the type of a table column.
         Depending on the implementation language it might also be allowed
!        to specify <quote>pseudotypes</> such as <type>cstring</>.
         If the function is not supposed to return a value, specify
         <type>void</> as the return type.
        </para>
--- 199,205 ----
         can be a base, composite, or domain type,
         or can reference the type of a table column.
         Depending on the implementation language it might also be allowed
!        to specify <quote>pseudo-types</> such as <type>cstring</>.
         If the function is not supposed to return a value, specify
         <type>void</> as the return type.
        </para>
diff --git a/doc/src/sgml/ref/create_type.sgml b/doc/src/sgml/ref/create_type.sgml
index 5a09f19..7146c4a 100644
*** a/doc/src/sgml/ref/create_type.sgml
--- b/doc/src/sgml/ref/create_type.sgml
*************** CREATE TYPE <replaceable class="paramete
*** 824,830 ****
     In <productname>PostgreSQL</productname> versions before 7.3, it
     was customary to avoid creating a shell type at all, by replacing the
     functions' forward references to the type name with the placeholder
!    pseudotype <type>opaque</>.  The <type>cstring</> arguments and
     results also had to be declared as <type>opaque</> before 7.3.  To
     support loading of old dump files, <command>CREATE TYPE</> will
     accept I/O functions declared using <type>opaque</>, but it will issue
--- 824,830 ----
     In <productname>PostgreSQL</productname> versions before 7.3, it
     was customary to avoid creating a shell type at all, by replacing the
     functions' forward references to the type name with the placeholder
!    pseudo-type <type>opaque</>.  The <type>cstring</> arguments and
     results also had to be declared as <type>opaque</> before 7.3.  To
     support loading of old dump files, <command>CREATE TYPE</> will
     accept I/O functions declared using <type>opaque</>, but it will issue
diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c
index af6ba47..51db1c6 100644
*** a/src/backend/catalog/heap.c
--- b/src/backend/catalog/heap.c
*************** CheckAttributeType(const char *attname,
*** 490,497 ****
      char        att_typtype = get_typtype(atttypid);
      Oid            att_typelem;

!     if (atttypid == UNKNOWNOID ||
!         att_typtype == TYPTYPE_PSEUDO)
      {
          /*
           * Refuse any attempt to create a pseudo-type column, except for a
--- 490,496 ----
      char        att_typtype = get_typtype(atttypid);
      Oid            att_typelem;

!     if (att_typtype == TYPTYPE_PSEUDO)
      {
          /*
           * Refuse any attempt to create a pseudo-type column, except for a
diff --git a/src/include/catalog/pg_type.h b/src/include/catalog/pg_type.h
index c2350f3..6e4c65e 100644
*** a/src/include/catalog/pg_type.h
--- b/src/include/catalog/pg_type.h
*************** DESCR("relative, limited-range time inte
*** 418,424 ****
  DATA(insert OID = 704 (  tinterval PGNSP PGUID 12 f b T f t \054 0     0 1025 tintervalin tintervalout tintervalrecv
tintervalsend- - - i p f 0 -1 0 0 _null_ _null_ _null_ )); 
  DESCR("(abstime,abstime), time interval");
  #define TINTERVALOID    704
! DATA(insert OID = 705 (  unknown   PGNSP PGUID -2 f b X f t \054 0     0 0 unknownin unknownout unknownrecv
unknownsend- - - c p f 0 -1 0 0 _null_ _null_ _null_ )); 
  DESCR("");
  #define UNKNOWNOID        705

--- 418,424 ----
  DATA(insert OID = 704 (  tinterval PGNSP PGUID 12 f b T f t \054 0     0 1025 tintervalin tintervalout tintervalrecv
tintervalsend- - - i p f 0 -1 0 0 _null_ _null_ _null_ )); 
  DESCR("(abstime,abstime), time interval");
  #define TINTERVALOID    704
! DATA(insert OID = 705 (  unknown   PGNSP PGUID -2 f p X f t \054 0     0 0 unknownin unknownout unknownrecv
unknownsend- - - c p f 0 -1 0 0 _null_ _null_ _null_ )); 
  DESCR("");
  #define UNKNOWNOID        705

diff --git a/src/test/regress/expected/type_sanity.out b/src/test/regress/expected/type_sanity.out
index e5adfba..312d290 100644
*** a/src/test/regress/expected/type_sanity.out
--- b/src/test/regress/expected/type_sanity.out
*************** WHERE (p1.typtype = 'c' AND p1.typrelid
*** 59,65 ****
  -- Look for types that should have an array type according to their typtype,
  -- but don't.  We exclude composites here because we have not bothered to
  -- make array types corresponding to the system catalogs' rowtypes.
! -- NOTE: as of 9.1, this check finds pg_node_tree, smgr, and unknown.
  SELECT p1.oid, p1.typname
  FROM pg_type as p1
  WHERE p1.typtype not in ('c','d','p') AND p1.typname NOT LIKE E'\\_%'
--- 59,65 ----
  -- Look for types that should have an array type according to their typtype,
  -- but don't.  We exclude composites here because we have not bothered to
  -- make array types corresponding to the system catalogs' rowtypes.
! -- NOTE: as of v10, this check finds pg_node_tree and smgr.
  SELECT p1.oid, p1.typname
  FROM pg_type as p1
  WHERE p1.typtype not in ('c','d','p') AND p1.typname NOT LIKE E'\\_%'
*************** WHERE p1.typtype not in ('c','d','p') AN
*** 71,78 ****
  -----+--------------
   194 | pg_node_tree
   210 | smgr
!  705 | unknown
! (3 rows)

  -- Make sure typarray points to a varlena array type of our own base
  SELECT p1.oid, p1.typname as basetype, p2.typname as arraytype,
--- 71,77 ----
  -----+--------------
   194 | pg_node_tree
   210 | smgr
! (2 rows)

  -- Make sure typarray points to a varlena array type of our own base
  SELECT p1.oid, p1.typname as basetype, p2.typname as arraytype,
diff --git a/src/test/regress/sql/type_sanity.sql b/src/test/regress/sql/type_sanity.sql
index f7c5c9d..0282f84 100644
*** a/src/test/regress/sql/type_sanity.sql
--- b/src/test/regress/sql/type_sanity.sql
*************** WHERE (p1.typtype = 'c' AND p1.typrelid
*** 53,59 ****
  -- Look for types that should have an array type according to their typtype,
  -- but don't.  We exclude composites here because we have not bothered to
  -- make array types corresponding to the system catalogs' rowtypes.
! -- NOTE: as of 9.1, this check finds pg_node_tree, smgr, and unknown.

  SELECT p1.oid, p1.typname
  FROM pg_type as p1
--- 53,59 ----
  -- Look for types that should have an array type according to their typtype,
  -- but don't.  We exclude composites here because we have not bothered to
  -- make array types corresponding to the system catalogs' rowtypes.
! -- NOTE: as of v10, this check finds pg_node_tree and smgr.

  SELECT p1.oid, p1.typname
  FROM pg_type as p1

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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: [HACKERS] Active zombies at AIX
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)