mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-09-28 00:11:53 +02:00
8272749e8c
When creating a cast that uses a conversion function, we've historically allowed the input and result types to be binary-compatible with the function's input and result types, rather than necessarily being identical. This means that the new cast is logically dependent on the binary-compatible cast or casts that it references: if those are defined by pg_cast entries, and you try to restore the new cast without having defined them, it'll fail. Hence, we should make pg_depend entries to record these dependencies so that pg_dump knows that there is an ordering requirement. This is not the only place where we allow such shortcuts; aggregate functions for example are similarly lax, and in principle should gain similar dependencies. However, for now it seems sufficient to fix the cast-versus-cast case, as pg_dump's other ordering heuristics should keep it out of trouble for other object types. Per report from David Turoň; thanks also to Robert Haas for preliminary investigation. I considered back-patching, but seeing that this issue has existed for many years without previous reports, it's not clear it's worth the trouble. Moreover, back-patching wouldn't be enough to ensure that the new pg_depend entries exist in existing databases anyway. Discussion: https://postgr.es/m/OF0A160F3E.578B15D1-ONC12588DA.003E4857-C12588DA.0045A428@notes.linuxbox.cz
76 lines
2.3 KiB
PL/PgSQL
76 lines
2.3 KiB
PL/PgSQL
--
|
|
-- CREATE_CAST
|
|
--
|
|
|
|
-- Create some types to test with
|
|
CREATE TYPE casttesttype;
|
|
|
|
CREATE FUNCTION casttesttype_in(cstring)
|
|
RETURNS casttesttype
|
|
AS 'textin'
|
|
LANGUAGE internal STRICT IMMUTABLE;
|
|
CREATE FUNCTION casttesttype_out(casttesttype)
|
|
RETURNS cstring
|
|
AS 'textout'
|
|
LANGUAGE internal STRICT IMMUTABLE;
|
|
|
|
CREATE TYPE casttesttype (
|
|
internallength = variable,
|
|
input = casttesttype_in,
|
|
output = casttesttype_out,
|
|
alignment = int4
|
|
);
|
|
|
|
-- a dummy function to test with
|
|
CREATE FUNCTION casttestfunc(casttesttype) RETURNS int4 LANGUAGE SQL AS
|
|
$$ SELECT 1; $$;
|
|
|
|
SELECT casttestfunc('foo'::text); -- fails, as there's no cast
|
|
|
|
-- Try binary coercion cast
|
|
CREATE CAST (text AS casttesttype) WITHOUT FUNCTION;
|
|
SELECT casttestfunc('foo'::text); -- doesn't work, as the cast is explicit
|
|
SELECT casttestfunc('foo'::text::casttesttype); -- should work
|
|
DROP CAST (text AS casttesttype); -- cleanup
|
|
|
|
-- Try IMPLICIT binary coercion cast
|
|
CREATE CAST (text AS casttesttype) WITHOUT FUNCTION AS IMPLICIT;
|
|
SELECT casttestfunc('foo'::text); -- Should work now
|
|
|
|
-- Try I/O conversion cast.
|
|
SELECT 1234::int4::casttesttype; -- No cast yet, should fail
|
|
|
|
CREATE CAST (int4 AS casttesttype) WITH INOUT;
|
|
SELECT 1234::int4::casttesttype; -- Should work now
|
|
|
|
DROP CAST (int4 AS casttesttype);
|
|
|
|
-- Try cast with a function
|
|
|
|
CREATE FUNCTION int4_casttesttype(int4) RETURNS casttesttype LANGUAGE SQL AS
|
|
$$ SELECT ('foo'::text || $1::text)::casttesttype; $$;
|
|
|
|
CREATE CAST (int4 AS casttesttype) WITH FUNCTION int4_casttesttype(int4) AS IMPLICIT;
|
|
SELECT 1234::int4::casttesttype; -- Should work now
|
|
|
|
DROP FUNCTION int4_casttesttype(int4) CASCADE;
|
|
|
|
-- Try it with a function that requires an implicit cast
|
|
|
|
CREATE FUNCTION bar_int4_text(int4) RETURNS text LANGUAGE SQL AS
|
|
$$ SELECT ('bar'::text || $1::text); $$;
|
|
|
|
CREATE CAST (int4 AS casttesttype) WITH FUNCTION bar_int4_text(int4) AS IMPLICIT;
|
|
SELECT 1234::int4::casttesttype; -- Should work now
|
|
|
|
-- check dependencies generated for that
|
|
SELECT pg_describe_object(classid, objid, objsubid) as obj,
|
|
pg_describe_object(refclassid, refobjid, refobjsubid) as objref,
|
|
deptype
|
|
FROM pg_depend
|
|
WHERE classid = 'pg_cast'::regclass AND
|
|
objid = (SELECT oid FROM pg_cast
|
|
WHERE castsource = 'int4'::regtype
|
|
AND casttarget = 'casttesttype'::regtype)
|
|
ORDER BY refclassid;
|