|From:||Frédéric Rejol <frederic(dot)rejol(at)sescoi(dot)fr>|
|Subject:||pg_dump not including custom CAST based on table types|
|Views:||Raw Message | Whole Thread | Download mbox|
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)
LANGUAGE PLPGSQL VOLATILE;
CREATE CAST (foo_source AS foo_target)
WITH FUNCTION cast_ident(foo_source)
--Casting works fine
SELECT (row(1)::foo_source)::foo_target as result;
--I can find the cast description in the catalog system.
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
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?
|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|