Re: pgsql-server/src/bin/pg_dump pg_backup_archiver.c - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql-server/src/bin/pg_dump pg_backup_archiver.c
Date
Msg-id 21866.1044138844@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql-server/src/bin/pg_dump pg_backup_archiver.c  (Hiroshi Inoue <Inoue@tpf.co.jp>)
List pgsql-committers
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> Unfortunately I don't have an infinite time and it's
> about time I give up the discussion. Feel free to revert
> my change. It's useless unless it is committed to 7.3 tree
> ASAP. I have little time this week anyway.

I found that it's possible to modify the queries issued by FixupBlobRefs
so that they work with the declarations created from either 7.2 or 7.3
versions of contrib/lo.  (Rather than assuming a cast exists, we can
write the function call lo(oid) or oid(lo) instead.)

This seems a much safer and more localized solution than having
pg_restore try to update the function definitions and create casts.

A related but independent problem is that 7.3 pg_dump tries to add
a CREATE CAST command when it sees a function that would have been
treated as a cast by earlier releases.  The CREATE CAST command would
fail if the existing function was marked volatile --- which is the
default, and so quite likely to be the case for user-defined functions.
I've fixed this by removing the prohibition against volatile cast
functions (which was something that I was unhappy with from the first,
IIRC).

            regards, tom lane

pgsql-committers by date:

Previous
From: tgl@postgresql.org (Tom Lane)
Date:
Subject: pgsql-server/ oc/src/sgml/ref/Tag: oc/src/sgml ...
Next
From: tgl@postgresql.org (Tom Lane)
Date:
Subject: pgsql-server/src/backend/executor nodeUnique.c