I wrote:
> Ashutosh Bapat <[email protected]> writes:
>> UNKNOWN is not exactly a pseudo-type.
> Well, as I said to Michael just now, I think we should turn it into one
> now that we're disallowing it in tables, because "cannot be used as a
> table column" is more or less the definition of a pseudotype.
I experimented with this, and it actually doesn't seem to be any harder
than the attached: there's one type_sanity query that changes results,
and otherwise all the regression tests pass.
I've grepped the code for references to UNKNOWNOID and TYPTYPE_PSEUDO,
and I can't find any places where the behavior would change in a way
that we don't want. Basically it looks like we'd disallow UNKNOWN as
a domain base, a PL function argument or result, and a plpgsql local
variable; and all of those seem like good things from here.
Have not checked the docs.
regards, tom lane
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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
