pg_dump not including custom CAST based on table types

From: Frédéric Rejol <frederic(dot)rejol(at)sescoi(dot)fr>
To: pgsql-general(at)postgresql(dot)org
Subject: pg_dump not including custom CAST based on table types
Date: 2011-10-18 14:27:16
Message-ID: j7k2cu$2u5e$
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-general

I created a custom CAST to cast from one table type to another.
pg_dump does not include my custom CAST.

Here is an example:

CREATE TABLE foo_source(id integer);
CREATE TABLE foo_target(id integer);

CREATE OR REPLACE FUNCTION cast_ident(foo_source)
RETURNS foo_target
result foo_target;
RETURN result;

CREATE CAST (foo_source AS foo_target)
WITH FUNCTION cast_ident(foo_source)
AS assignment;

--Casting works fine
SELECT (row(1)::foo_source)::foo_target as result;

--I can find the cast description in the catalog system.
SELECT castfunc::regprocedure,castsource::regtype,casttarget::regtype
FROM pg_cast
WHERE castsource='foo_source'::regtype and casttarget='foo_target'::regtype;

pg_dump -s -U postgres test > test.sql

when I look at the "test.sql" dumped file, I cannot find the CAST command.

I read carrefully the archives regarding my problem.

Michael Glaesemann <grzm(at)seespotcode(dot)net> writes:
> On Nov 17, 2007, at 0:36 , Tom Lane wrote:
>> pg_dump thinks it's a built-in system object.

> What other objects might be susceptible to this? Operators? Operator
> classes?

It's just casts. They're a bit of a problem since they have neither
owners nor schemas, so there's not anything very concrete to base a
dump-or-don't-dump decision on. The rule pg_dump uses is to dump it
if at least one of the three underlying objects (source type, dest type,
or function) is dumpable. Here you've got 2 builtin types and
no function, so you lose.

regards, tom lane

My underlying objects are two tables foo_source and foo_target that can
be assimilated to types and they are dumpable.

Is there another rule or is it a bug?

Frédéric Rejol.


Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2011-10-18 14:50:23 Re: Out of Memory Error on Insert
Previous Message Deshpande, Yogesh Sadashiv (STSD-Openview) 2011-10-18 13:57:08 Postgre Performance