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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql-server/src/bin/pg_dump pg_backup_archiver.c
Date: 2003-02-01 22:34:04
Message-ID: 21866.1044138844@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2003-02-02 19:08:57 pgsql-server/src/backend/executor nodeUnique.c
Previous Message Tom Lane 2003-02-01 22:09:41 pgsql-server/ oc/src/sgml/ref/Tag: oc/src/sgml ...