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
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 ... |