2000-01-05 18:31:08 +01:00
|
|
|
--
|
|
|
|
-- CREATE_TYPE
|
|
|
|
--
|
2022-02-08 21:30:38 +01:00
|
|
|
-- directory path and dlsuffix are passed to us in environment variables
|
|
|
|
\getenv libdir PG_LIBDIR
|
|
|
|
\getenv dlsuffix PG_DLSUFFIX
|
|
|
|
\set regresslib :libdir '/regress' :dlsuffix
|
2006-02-28 23:37:27 +01:00
|
|
|
--
|
2022-02-08 21:30:38 +01:00
|
|
|
-- Test the "old style" approach of making the I/O functions first,
|
|
|
|
-- with no explicit shell type creation.
|
2006-02-28 23:37:27 +01:00
|
|
|
--
|
2022-02-08 21:30:38 +01:00
|
|
|
CREATE FUNCTION widget_in(cstring)
|
|
|
|
RETURNS widget
|
|
|
|
AS :'regresslib'
|
|
|
|
LANGUAGE C STRICT IMMUTABLE;
|
|
|
|
NOTICE: type "widget" is not yet defined
|
|
|
|
DETAIL: Creating a shell type definition.
|
|
|
|
CREATE FUNCTION widget_out(widget)
|
|
|
|
RETURNS cstring
|
|
|
|
AS :'regresslib'
|
|
|
|
LANGUAGE C STRICT IMMUTABLE;
|
|
|
|
NOTICE: argument type widget is only a shell
|
|
|
|
CREATE FUNCTION int44in(cstring)
|
|
|
|
RETURNS city_budget
|
|
|
|
AS :'regresslib'
|
|
|
|
LANGUAGE C STRICT IMMUTABLE;
|
|
|
|
NOTICE: type "city_budget" is not yet defined
|
|
|
|
DETAIL: Creating a shell type definition.
|
|
|
|
CREATE FUNCTION int44out(city_budget)
|
|
|
|
RETURNS cstring
|
|
|
|
AS :'regresslib'
|
|
|
|
LANGUAGE C STRICT IMMUTABLE;
|
|
|
|
NOTICE: argument type city_budget is only a shell
|
2000-01-05 18:31:08 +01:00
|
|
|
CREATE TYPE widget (
|
2010-11-23 21:27:50 +01:00
|
|
|
internallength = 24,
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
input = widget_in,
|
|
|
|
output = widget_out,
|
2006-12-30 22:21:56 +01:00
|
|
|
typmod_in = numerictypmodin,
|
|
|
|
typmod_out = numerictypmodout,
|
1997-04-05 23:26:00 +02:00
|
|
|
alignment = double
|
|
|
|
);
|
2010-11-23 21:27:50 +01:00
|
|
|
CREATE TYPE city_budget (
|
|
|
|
internallength = 16,
|
2018-02-27 21:15:35 +01:00
|
|
|
input = int44in,
|
|
|
|
output = int44out,
|
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
|
|
|
element = int4,
|
|
|
|
category = 'x', -- just to verify the system will take it
|
2008-07-30 21:35:13 +02:00
|
|
|
preferred = true -- ditto
|
1997-04-05 23:26:00 +02:00
|
|
|
);
|
2006-02-28 23:37:27 +01:00
|
|
|
-- Test creation and destruction of shell types
|
|
|
|
CREATE TYPE shell;
|
|
|
|
CREATE TYPE shell; -- fail, type already present
|
|
|
|
ERROR: type "shell" already exists
|
|
|
|
DROP TYPE shell;
|
|
|
|
DROP TYPE shell; -- fail, type not exist
|
|
|
|
ERROR: type "shell" does not exist
|
2015-08-05 01:34:12 +02:00
|
|
|
-- also, let's leave one around for purposes of pg_dump testing
|
|
|
|
CREATE TYPE myshell;
|
2006-02-28 23:37:27 +01:00
|
|
|
--
|
2001-09-06 04:07:42 +02:00
|
|
|
-- Test type-related default values (broken in releases before PG 7.2)
|
2006-02-28 23:37:27 +01:00
|
|
|
--
|
|
|
|
-- This part of the test also exercises the "new style" approach of making
|
|
|
|
-- a shell type and then filling it in.
|
|
|
|
--
|
|
|
|
CREATE TYPE int42;
|
|
|
|
CREATE TYPE text_w_default;
|
2002-08-22 02:01:51 +02:00
|
|
|
-- Make dummy I/O routines using the existing internal support for int4, text
|
|
|
|
CREATE FUNCTION int42_in(cstring)
|
|
|
|
RETURNS int42
|
|
|
|
AS 'int4in'
|
2014-11-05 17:44:06 +01:00
|
|
|
LANGUAGE internal STRICT IMMUTABLE;
|
2006-02-28 23:37:27 +01:00
|
|
|
NOTICE: return type int42 is only a shell
|
2002-08-22 02:01:51 +02:00
|
|
|
CREATE FUNCTION int42_out(int42)
|
|
|
|
RETURNS cstring
|
|
|
|
AS 'int4out'
|
2014-11-05 17:44:06 +01:00
|
|
|
LANGUAGE internal STRICT IMMUTABLE;
|
2003-07-19 01:20:33 +02:00
|
|
|
NOTICE: argument type int42 is only a shell
|
2002-08-22 02:01:51 +02:00
|
|
|
CREATE FUNCTION text_w_default_in(cstring)
|
|
|
|
RETURNS text_w_default
|
|
|
|
AS 'textin'
|
2014-11-05 17:44:06 +01:00
|
|
|
LANGUAGE internal STRICT IMMUTABLE;
|
2006-02-28 23:37:27 +01:00
|
|
|
NOTICE: return type text_w_default is only a shell
|
2002-08-22 02:01:51 +02:00
|
|
|
CREATE FUNCTION text_w_default_out(text_w_default)
|
|
|
|
RETURNS cstring
|
|
|
|
AS 'textout'
|
2014-11-05 17:44:06 +01:00
|
|
|
LANGUAGE internal STRICT IMMUTABLE;
|
2003-07-19 01:20:33 +02:00
|
|
|
NOTICE: argument type text_w_default is only a shell
|
2001-09-06 04:07:42 +02:00
|
|
|
CREATE TYPE int42 (
|
|
|
|
internallength = 4,
|
2002-08-22 02:01:51 +02:00
|
|
|
input = int42_in,
|
|
|
|
output = int42_out,
|
2001-09-06 04:07:42 +02:00
|
|
|
alignment = int4,
|
|
|
|
default = 42,
|
|
|
|
passedbyvalue
|
|
|
|
);
|
|
|
|
CREATE TYPE text_w_default (
|
|
|
|
internallength = variable,
|
2002-08-22 02:01:51 +02:00
|
|
|
input = text_w_default_in,
|
|
|
|
output = text_w_default_out,
|
2001-09-06 04:07:42 +02:00
|
|
|
alignment = int4,
|
|
|
|
default = 'zippo'
|
|
|
|
);
|
|
|
|
CREATE TABLE default_test (f1 text_w_default, f2 int42);
|
|
|
|
INSERT INTO default_test DEFAULT VALUES;
|
|
|
|
SELECT * FROM default_test;
|
|
|
|
f1 | f2
|
|
|
|
-------+----
|
|
|
|
zippo | 42
|
|
|
|
(1 row)
|
|
|
|
|
2020-03-05 21:48:56 +01:00
|
|
|
-- We need a shell type to test some CREATE TYPE failure cases with
|
|
|
|
CREATE TYPE bogus_type;
|
Avoid unnecessary use of pg_strcasecmp for already-downcased identifiers.
We have a lot of code in which option names, which from the user's
viewpoint are logically keywords, are passed through the grammar as plain
identifiers, and then matched to string literals during command execution.
This approach avoids making words into lexer keywords unnecessarily. Some
places matched these strings using plain strcmp, some using pg_strcasecmp.
But the latter should be unnecessary since identifiers would have been
downcased on their way through the parser. Aside from any efficiency
concerns (probably not a big factor), the lack of consistency in this area
creates a hazard of subtle bugs due to different places coming to different
conclusions about whether two option names are the same or different.
Hence, standardize on using strcmp() to match any option names that are
expected to have been fed through the parser.
This does create a user-visible behavioral change, which is that while
formerly all of these would work:
alter table foo set (fillfactor = 50);
alter table foo set (FillFactor = 50);
alter table foo set ("fillfactor" = 50);
alter table foo set ("FillFactor" = 50);
now the last case will fail because that double-quoted identifier is
different from the others. However, none of our documentation says that
you can use a quoted identifier in such contexts at all, and we should
discourage doing so since it would break if we ever decide to parse such
constructs as true lexer keywords rather than poor man's substitutes.
So this shouldn't create a significant compatibility issue for users.
Daniel Gustafsson, reviewed by Michael Paquier, small changes by me
Discussion: https://postgr.es/m/29405B24-564E-476B-98C0-677A29805B84@yesql.se
2018-01-27 00:25:02 +01:00
|
|
|
-- invalid: non-lowercase quoted identifiers
|
2020-03-05 21:48:56 +01:00
|
|
|
CREATE TYPE bogus_type (
|
Avoid unnecessary use of pg_strcasecmp for already-downcased identifiers.
We have a lot of code in which option names, which from the user's
viewpoint are logically keywords, are passed through the grammar as plain
identifiers, and then matched to string literals during command execution.
This approach avoids making words into lexer keywords unnecessarily. Some
places matched these strings using plain strcmp, some using pg_strcasecmp.
But the latter should be unnecessary since identifiers would have been
downcased on their way through the parser. Aside from any efficiency
concerns (probably not a big factor), the lack of consistency in this area
creates a hazard of subtle bugs due to different places coming to different
conclusions about whether two option names are the same or different.
Hence, standardize on using strcmp() to match any option names that are
expected to have been fed through the parser.
This does create a user-visible behavioral change, which is that while
formerly all of these would work:
alter table foo set (fillfactor = 50);
alter table foo set (FillFactor = 50);
alter table foo set ("fillfactor" = 50);
alter table foo set ("FillFactor" = 50);
now the last case will fail because that double-quoted identifier is
different from the others. However, none of our documentation says that
you can use a quoted identifier in such contexts at all, and we should
discourage doing so since it would break if we ever decide to parse such
constructs as true lexer keywords rather than poor man's substitutes.
So this shouldn't create a significant compatibility issue for users.
Daniel Gustafsson, reviewed by Michael Paquier, small changes by me
Discussion: https://postgr.es/m/29405B24-564E-476B-98C0-677A29805B84@yesql.se
2018-01-27 00:25:02 +01:00
|
|
|
"Internallength" = 4,
|
|
|
|
"Input" = int42_in,
|
|
|
|
"Output" = int42_out,
|
|
|
|
"Alignment" = int4,
|
|
|
|
"Default" = 42,
|
|
|
|
"Passedbyvalue"
|
|
|
|
);
|
|
|
|
WARNING: type attribute "Internallength" not recognized
|
|
|
|
LINE 2: "Internallength" = 4,
|
|
|
|
^
|
|
|
|
WARNING: type attribute "Input" not recognized
|
|
|
|
LINE 3: "Input" = int42_in,
|
|
|
|
^
|
|
|
|
WARNING: type attribute "Output" not recognized
|
|
|
|
LINE 4: "Output" = int42_out,
|
|
|
|
^
|
|
|
|
WARNING: type attribute "Alignment" not recognized
|
|
|
|
LINE 5: "Alignment" = int4,
|
|
|
|
^
|
|
|
|
WARNING: type attribute "Default" not recognized
|
|
|
|
LINE 6: "Default" = 42,
|
|
|
|
^
|
|
|
|
WARNING: type attribute "Passedbyvalue" not recognized
|
|
|
|
LINE 7: "Passedbyvalue"
|
|
|
|
^
|
|
|
|
ERROR: type input function must be specified
|
2020-03-05 21:48:56 +01:00
|
|
|
-- invalid: input/output function incompatibility
|
|
|
|
CREATE TYPE bogus_type (INPUT = array_in,
|
|
|
|
OUTPUT = array_out,
|
|
|
|
ELEMENT = int,
|
|
|
|
INTERNALLENGTH = 32);
|
|
|
|
ERROR: type input function array_in must return type bogus_type
|
|
|
|
DROP TYPE bogus_type;
|
|
|
|
-- It no longer is possible to issue CREATE TYPE without making a shell first
|
|
|
|
CREATE TYPE bogus_type (INPUT = array_in,
|
|
|
|
OUTPUT = array_out,
|
|
|
|
ELEMENT = int,
|
|
|
|
INTERNALLENGTH = 32);
|
|
|
|
ERROR: type "bogus_type" does not exist
|
|
|
|
HINT: Create the type as a shell type, then create its I/O functions, then do a full CREATE TYPE.
|
2002-08-15 18:36:08 +02:00
|
|
|
-- Test stand-alone composite type
|
|
|
|
CREATE TYPE default_test_row AS (f1 text_w_default, f2 int42);
|
|
|
|
CREATE FUNCTION get_default_test() RETURNS SETOF default_test_row AS '
|
|
|
|
SELECT * FROM default_test;
|
|
|
|
' LANGUAGE SQL;
|
|
|
|
SELECT * FROM get_default_test();
|
|
|
|
f1 | f2
|
|
|
|
-------+----
|
|
|
|
zippo | 42
|
|
|
|
(1 row)
|
|
|
|
|
2003-11-21 23:32:49 +01:00
|
|
|
-- Test comments
|
|
|
|
COMMENT ON TYPE bad IS 'bad comment';
|
|
|
|
ERROR: type "bad" does not exist
|
|
|
|
COMMENT ON TYPE default_test_row IS 'good comment';
|
|
|
|
COMMENT ON TYPE default_test_row IS NULL;
|
2010-10-19 13:21:58 +02:00
|
|
|
COMMENT ON COLUMN default_test_row.nope IS 'bad comment';
|
|
|
|
ERROR: column "nope" of relation "default_test_row" does not exist
|
|
|
|
COMMENT ON COLUMN default_test_row.f1 IS 'good comment';
|
|
|
|
COMMENT ON COLUMN default_test_row.f1 IS NULL;
|
2006-02-28 23:37:27 +01:00
|
|
|
-- Check shell type create for existing types
|
|
|
|
CREATE TYPE text_w_default; -- should fail
|
|
|
|
ERROR: type "text_w_default" already exists
|
2002-08-15 18:36:08 +02:00
|
|
|
DROP TYPE default_test_row CASCADE;
|
2003-07-21 03:59:11 +02:00
|
|
|
NOTICE: drop cascades to function get_default_test()
|
2001-09-06 04:07:42 +02:00
|
|
|
DROP TABLE default_test;
|
2020-03-05 21:48:56 +01:00
|
|
|
-- Check dependencies are established when creating a new type
|
|
|
|
CREATE TYPE base_type;
|
|
|
|
CREATE FUNCTION base_fn_in(cstring) RETURNS base_type AS 'boolin'
|
2017-06-16 10:33:12 +02:00
|
|
|
LANGUAGE internal IMMUTABLE STRICT;
|
2020-03-05 21:48:56 +01:00
|
|
|
NOTICE: return type base_type is only a shell
|
|
|
|
CREATE FUNCTION base_fn_out(base_type) RETURNS cstring AS 'boolout'
|
2017-06-16 10:33:12 +02:00
|
|
|
LANGUAGE internal IMMUTABLE STRICT;
|
2020-03-05 21:48:56 +01:00
|
|
|
NOTICE: argument type base_type is only a shell
|
2017-06-16 10:33:12 +02:00
|
|
|
CREATE TYPE base_type(INPUT = base_fn_in, OUTPUT = base_fn_out);
|
|
|
|
DROP FUNCTION base_fn_in(cstring); -- error
|
|
|
|
ERROR: cannot drop function base_fn_in(cstring) because other objects depend on it
|
|
|
|
DETAIL: type base_type depends on function base_fn_in(cstring)
|
|
|
|
function base_fn_out(base_type) depends on type base_type
|
|
|
|
HINT: Use DROP ... CASCADE to drop the dependent objects too.
|
2020-03-05 21:48:56 +01:00
|
|
|
DROP FUNCTION base_fn_out(base_type); -- error
|
|
|
|
ERROR: cannot drop function base_fn_out(base_type) because other objects depend on it
|
|
|
|
DETAIL: type base_type depends on function base_fn_out(base_type)
|
|
|
|
function base_fn_in(cstring) depends on type base_type
|
|
|
|
HINT: Use DROP ... CASCADE to drop the dependent objects too.
|
2017-06-16 10:33:12 +02:00
|
|
|
DROP TYPE base_type; -- error
|
|
|
|
ERROR: cannot drop type base_type because other objects depend on it
|
Sort the dependent objects before recursing in findDependentObjects().
Historically, the notices output by DROP CASCADE tended to come out
in uncertain order, and in some cases you might get different claims
about which object depends on which other one. This is because we
just traversed the dependency tree in the order in which pg_depend
entries are seen, and nbtree has never promised anything about the
order of equal-keyed index entries. We've put up with that for years,
hacking regression tests when necessary to prevent them from emitting
unstable output. However, it's a problem for pending work that will
change nbtree's behavior for equal keys, as that causes unexpected
changes in the regression test results.
Hence, adjust findDependentObjects to sort the results of each
indexscan before processing them. The sort is on descending OID of
the dependent objects, hence more or less reverse creation order.
While this rule could still result in bogus regression test failures
if an OID wraparound occurred mid-test, that seems unlikely to happen
in any plausible development or packaging-test scenario.
This is enough to ensure output stability for ordinary DROP CASCADE
commands, but not for DROP OWNED BY, because that has a different
code path with the same problem. We might later choose to sort in
the DROP OWNED BY code as well, but this patch doesn't do so.
I've also not done anything about reverting the existing hacks to
suppress unstable DROP CASCADE output in specific regression tests.
It might be worth undoing those, but it seems like a distinct question.
The first indexscan loop in findDependentObjects is not touched,
meaning there is a hazard of unstable error reports from that too.
However, said hazard is not the fault of that code: it was designed
on the assumption that there could be at most one "owning" object
to complain about, and that assumption does not seem unreasonable.
The recent patch that added the possibility of multiple
DEPENDENCY_INTERNAL_AUTO links broke that assumption, but we should
fix that situation not band-aid around it. That's a matter for
another patch, though.
Discussion: https://postgr.es/m/12244.1547854440@sss.pgh.pa.us
2019-01-21 19:48:07 +01:00
|
|
|
DETAIL: function base_fn_in(cstring) depends on type base_type
|
|
|
|
function base_fn_out(base_type) depends on type base_type
|
2017-06-16 10:33:12 +02:00
|
|
|
HINT: Use DROP ... CASCADE to drop the dependent objects too.
|
|
|
|
DROP TYPE base_type CASCADE;
|
|
|
|
NOTICE: drop cascades to 2 other objects
|
Sort the dependent objects before recursing in findDependentObjects().
Historically, the notices output by DROP CASCADE tended to come out
in uncertain order, and in some cases you might get different claims
about which object depends on which other one. This is because we
just traversed the dependency tree in the order in which pg_depend
entries are seen, and nbtree has never promised anything about the
order of equal-keyed index entries. We've put up with that for years,
hacking regression tests when necessary to prevent them from emitting
unstable output. However, it's a problem for pending work that will
change nbtree's behavior for equal keys, as that causes unexpected
changes in the regression test results.
Hence, adjust findDependentObjects to sort the results of each
indexscan before processing them. The sort is on descending OID of
the dependent objects, hence more or less reverse creation order.
While this rule could still result in bogus regression test failures
if an OID wraparound occurred mid-test, that seems unlikely to happen
in any plausible development or packaging-test scenario.
This is enough to ensure output stability for ordinary DROP CASCADE
commands, but not for DROP OWNED BY, because that has a different
code path with the same problem. We might later choose to sort in
the DROP OWNED BY code as well, but this patch doesn't do so.
I've also not done anything about reverting the existing hacks to
suppress unstable DROP CASCADE output in specific regression tests.
It might be worth undoing those, but it seems like a distinct question.
The first indexscan loop in findDependentObjects is not touched,
meaning there is a hazard of unstable error reports from that too.
However, said hazard is not the fault of that code: it was designed
on the assumption that there could be at most one "owning" object
to complain about, and that assumption does not seem unreasonable.
The recent patch that added the possibility of multiple
DEPENDENCY_INTERNAL_AUTO links broke that assumption, but we should
fix that situation not band-aid around it. That's a matter for
another patch, though.
Discussion: https://postgr.es/m/12244.1547854440@sss.pgh.pa.us
2019-01-21 19:48:07 +01:00
|
|
|
DETAIL: drop cascades to function base_fn_in(cstring)
|
|
|
|
drop cascades to function base_fn_out(base_type)
|
2006-12-30 22:21:56 +01:00
|
|
|
-- Check usage of typmod with a user-defined type
|
|
|
|
-- (we have borrowed numeric's typmod functions)
|
|
|
|
CREATE TEMP TABLE mytab (foo widget(42,13,7)); -- should fail
|
|
|
|
ERROR: invalid NUMERIC type modifier
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: CREATE TEMP TABLE mytab (foo widget(42,13,7));
|
|
|
|
^
|
2006-12-30 22:21:56 +01:00
|
|
|
CREATE TEMP TABLE mytab (foo widget(42,13));
|
|
|
|
SELECT format_type(atttypid,atttypmod) FROM pg_attribute
|
|
|
|
WHERE attrelid = 'mytab'::regclass AND attnum > 0;
|
|
|
|
format_type
|
|
|
|
---------------
|
|
|
|
widget(42,13)
|
|
|
|
(1 row)
|
|
|
|
|
2018-02-27 18:13:14 +01:00
|
|
|
-- might as well exercise the widget type while we're here
|
|
|
|
INSERT INTO mytab VALUES ('(1,2,3)'), ('(-44,5.5,12)');
|
|
|
|
TABLE mytab;
|
|
|
|
foo
|
|
|
|
--------------
|
|
|
|
(1,2,3)
|
|
|
|
(-44,5.5,12)
|
|
|
|
(2 rows)
|
|
|
|
|
2018-03-01 17:37:46 +01:00
|
|
|
-- and test format_type() a bit more, too
|
|
|
|
select format_type('varchar'::regtype, 42);
|
|
|
|
format_type
|
|
|
|
-----------------------
|
|
|
|
character varying(38)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select format_type('bpchar'::regtype, null);
|
|
|
|
format_type
|
|
|
|
-------------
|
|
|
|
character
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- this behavior difference is intentional
|
|
|
|
select format_type('bpchar'::regtype, -1);
|
|
|
|
format_type
|
|
|
|
-------------
|
|
|
|
bpchar
|
|
|
|
(1 row)
|
|
|
|
|
2022-02-08 21:30:38 +01:00
|
|
|
-- Test creation of an operator over a user-defined type
|
|
|
|
CREATE FUNCTION pt_in_widget(point, widget)
|
|
|
|
RETURNS bool
|
|
|
|
AS :'regresslib'
|
|
|
|
LANGUAGE C STRICT;
|
|
|
|
CREATE OPERATOR <% (
|
|
|
|
leftarg = point,
|
|
|
|
rightarg = widget,
|
|
|
|
procedure = pt_in_widget,
|
|
|
|
commutator = >% ,
|
|
|
|
negator = >=%
|
|
|
|
);
|
|
|
|
SELECT point '(1,2)' <% widget '(0,0,3)' AS t,
|
|
|
|
point '(1,2)' <% widget '(0,0,1)' AS f;
|
|
|
|
t | f
|
|
|
|
---+---
|
|
|
|
t | f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- exercise city_budget type
|
|
|
|
CREATE TABLE city (
|
|
|
|
name name,
|
|
|
|
location box,
|
|
|
|
budget city_budget
|
|
|
|
);
|
|
|
|
INSERT INTO city VALUES
|
|
|
|
('Podunk', '(1,2),(3,4)', '100,127,1000'),
|
|
|
|
('Gotham', '(1000,34),(1100,334)', '123456,127,-1000,6789');
|
|
|
|
TABLE city;
|
|
|
|
name | location | budget
|
|
|
|
--------+----------------------+-----------------------
|
|
|
|
Podunk | (3,4),(1,2) | 100,127,1000,0
|
|
|
|
Gotham | (1100,334),(1000,34) | 123456,127,-1000,6789
|
|
|
|
(2 rows)
|
|
|
|
|
2020-03-06 18:19:29 +01:00
|
|
|
--
|
|
|
|
-- Test CREATE/ALTER TYPE using a type that's compatible with varchar,
|
|
|
|
-- so we can re-use those support functions
|
|
|
|
--
|
|
|
|
CREATE TYPE myvarchar;
|
|
|
|
CREATE FUNCTION myvarcharin(cstring, oid, integer) RETURNS myvarchar
|
|
|
|
LANGUAGE internal IMMUTABLE PARALLEL SAFE STRICT AS 'varcharin';
|
|
|
|
NOTICE: return type myvarchar is only a shell
|
|
|
|
CREATE FUNCTION myvarcharout(myvarchar) RETURNS cstring
|
|
|
|
LANGUAGE internal IMMUTABLE PARALLEL SAFE STRICT AS 'varcharout';
|
|
|
|
NOTICE: argument type myvarchar is only a shell
|
|
|
|
CREATE FUNCTION myvarcharsend(myvarchar) RETURNS bytea
|
|
|
|
LANGUAGE internal STABLE PARALLEL SAFE STRICT AS 'varcharsend';
|
|
|
|
NOTICE: argument type myvarchar is only a shell
|
|
|
|
CREATE FUNCTION myvarcharrecv(internal, oid, integer) RETURNS myvarchar
|
|
|
|
LANGUAGE internal STABLE PARALLEL SAFE STRICT AS 'varcharrecv';
|
|
|
|
NOTICE: return type myvarchar is only a shell
|
|
|
|
-- fail, it's still a shell:
|
|
|
|
ALTER TYPE myvarchar SET (storage = extended);
|
|
|
|
ERROR: type "myvarchar" is only a shell
|
|
|
|
CREATE TYPE myvarchar (
|
|
|
|
input = myvarcharin,
|
|
|
|
output = myvarcharout,
|
|
|
|
alignment = integer,
|
|
|
|
storage = main
|
|
|
|
);
|
|
|
|
-- want to check updating of a domain over the target type, too
|
|
|
|
CREATE DOMAIN myvarchardom AS myvarchar;
|
|
|
|
ALTER TYPE myvarchar SET (storage = plain); -- not allowed
|
|
|
|
ERROR: cannot change type's storage to PLAIN
|
|
|
|
ALTER TYPE myvarchar SET (storage = extended);
|
|
|
|
ALTER TYPE myvarchar SET (
|
|
|
|
send = myvarcharsend,
|
|
|
|
receive = myvarcharrecv,
|
|
|
|
typmod_in = varchartypmodin,
|
|
|
|
typmod_out = varchartypmodout,
|
2020-12-12 00:07:02 +01:00
|
|
|
-- these are bogus, but it's safe as long as we don't use the type:
|
|
|
|
analyze = ts_typanalyze,
|
|
|
|
subscript = raw_array_subscript_handler
|
2020-03-06 18:19:29 +01:00
|
|
|
);
|
|
|
|
SELECT typinput, typoutput, typreceive, typsend, typmodin, typmodout,
|
2020-12-12 00:07:02 +01:00
|
|
|
typanalyze, typsubscript, typstorage
|
2020-03-06 18:19:29 +01:00
|
|
|
FROM pg_type WHERE typname = 'myvarchar';
|
2020-12-12 00:07:02 +01:00
|
|
|
typinput | typoutput | typreceive | typsend | typmodin | typmodout | typanalyze | typsubscript | typstorage
|
|
|
|
-------------+--------------+---------------+---------------+-----------------+------------------+---------------+-----------------------------+------------
|
|
|
|
myvarcharin | myvarcharout | myvarcharrecv | myvarcharsend | varchartypmodin | varchartypmodout | ts_typanalyze | raw_array_subscript_handler | x
|
2020-03-06 18:19:29 +01:00
|
|
|
(1 row)
|
|
|
|
|
2020-07-31 23:11:28 +02:00
|
|
|
SELECT typinput, typoutput, typreceive, typsend, typmodin, typmodout,
|
2020-12-12 00:07:02 +01:00
|
|
|
typanalyze, typsubscript, typstorage
|
2020-07-31 23:11:28 +02:00
|
|
|
FROM pg_type WHERE typname = '_myvarchar';
|
2020-12-12 00:07:02 +01:00
|
|
|
typinput | typoutput | typreceive | typsend | typmodin | typmodout | typanalyze | typsubscript | typstorage
|
|
|
|
----------+-----------+------------+------------+-----------------+------------------+------------------+-------------------------+------------
|
|
|
|
array_in | array_out | array_recv | array_send | varchartypmodin | varchartypmodout | array_typanalyze | array_subscript_handler | x
|
2020-07-31 23:11:28 +02:00
|
|
|
(1 row)
|
|
|
|
|
2020-03-06 18:19:29 +01:00
|
|
|
SELECT typinput, typoutput, typreceive, typsend, typmodin, typmodout,
|
2020-12-12 00:07:02 +01:00
|
|
|
typanalyze, typsubscript, typstorage
|
2020-03-06 18:19:29 +01:00
|
|
|
FROM pg_type WHERE typname = 'myvarchardom';
|
2020-12-12 00:07:02 +01:00
|
|
|
typinput | typoutput | typreceive | typsend | typmodin | typmodout | typanalyze | typsubscript | typstorage
|
|
|
|
-----------+--------------+-------------+---------------+----------+-----------+---------------+--------------+------------
|
|
|
|
domain_in | myvarcharout | domain_recv | myvarcharsend | - | - | ts_typanalyze | - | x
|
2020-03-06 18:19:29 +01:00
|
|
|
(1 row)
|
|
|
|
|
2020-07-31 23:11:28 +02:00
|
|
|
SELECT typinput, typoutput, typreceive, typsend, typmodin, typmodout,
|
2020-12-12 00:07:02 +01:00
|
|
|
typanalyze, typsubscript, typstorage
|
2020-07-31 23:11:28 +02:00
|
|
|
FROM pg_type WHERE typname = '_myvarchardom';
|
2020-12-12 00:07:02 +01:00
|
|
|
typinput | typoutput | typreceive | typsend | typmodin | typmodout | typanalyze | typsubscript | typstorage
|
|
|
|
----------+-----------+------------+------------+----------+-----------+------------------+-------------------------+------------
|
|
|
|
array_in | array_out | array_recv | array_send | - | - | array_typanalyze | array_subscript_handler | x
|
2020-07-31 23:11:28 +02:00
|
|
|
(1 row)
|
|
|
|
|
2020-03-06 18:19:29 +01:00
|
|
|
-- ensure dependencies are straight
|
|
|
|
DROP FUNCTION myvarcharsend(myvarchar); -- fail
|
|
|
|
ERROR: cannot drop function myvarcharsend(myvarchar) because other objects depend on it
|
|
|
|
DETAIL: type myvarchar depends on function myvarcharsend(myvarchar)
|
|
|
|
function myvarcharin(cstring,oid,integer) depends on type myvarchar
|
|
|
|
function myvarcharout(myvarchar) depends on type myvarchar
|
|
|
|
function myvarcharrecv(internal,oid,integer) depends on type myvarchar
|
|
|
|
type myvarchardom depends on function myvarcharsend(myvarchar)
|
|
|
|
HINT: Use DROP ... CASCADE to drop the dependent objects too.
|
|
|
|
DROP TYPE myvarchar; -- fail
|
|
|
|
ERROR: cannot drop type myvarchar because other objects depend on it
|
|
|
|
DETAIL: function myvarcharin(cstring,oid,integer) depends on type myvarchar
|
|
|
|
function myvarcharout(myvarchar) depends on type myvarchar
|
|
|
|
function myvarcharsend(myvarchar) depends on type myvarchar
|
|
|
|
function myvarcharrecv(internal,oid,integer) depends on type myvarchar
|
|
|
|
type myvarchardom depends on type myvarchar
|
|
|
|
HINT: Use DROP ... CASCADE to drop the dependent objects too.
|
|
|
|
DROP TYPE myvarchar CASCADE;
|
|
|
|
NOTICE: drop cascades to 5 other objects
|
|
|
|
DETAIL: drop cascades to function myvarcharin(cstring,oid,integer)
|
|
|
|
drop cascades to function myvarcharout(myvarchar)
|
|
|
|
drop cascades to function myvarcharsend(myvarchar)
|
|
|
|
drop cascades to function myvarcharrecv(internal,oid,integer)
|
|
|
|
drop cascades to type myvarchardom
|