pgsql-server/src/bin/pg_dump pg_backup_archiver.c 
Author Message
 pgsql-server/src/bin/pg_dump pg_backup_archiver.c
CVSROOT:        /cvsroot
Module name:    pgsql-server

Modified files:
        src/bin/pg_dump: pg_backup_archiver.c

Log message:
        Adjust lo type in contrib during pg_restore so that pg_restore could
        reload the type.

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster



Wed, 22 Jun 2005 02:05:06 GMT
 pgsql-server/src/bin/pg_dump pg_backup_archiver.c

Quote:

>    src/bin/pg_dump: pg_backup_archiver.c
> Log message:
>    Adjust lo type in contrib during pg_restore so that pg_restore could
>    reload the type.

I find this really ugly, and I do not believe this code belongs in
pg_dump (nor pg_restore).  We are not in the habit of putting kluges
into pg_dump to adjust system catalog entries for version-to-version
changes, and I certainly don't think that we should put in such a kluge
for a type that's only contrib.

The correct way to update contrib/lo for 7.3 is to load the 7.3
definition into a database before restoring the old definition.

If someone fails to do that, it'd be okay to supply this fix as a script
in contrib/lo to run against the database after-the-fact.  But I object
to putting it into pg_restore.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command



Wed, 22 Jun 2005 05:48:55 GMT
 pgsql-server/src/bin/pg_dump pg_backup_archiver.c

Quote:
Tom Lane writes:
> The correct way to update contrib/lo for 7.3 is to load the 7.3
> definition into a database before restoring the old definition.

I'm not completely sure what the "lo" type provides, but if there was a
cast between oid and lo in 7.2 (by having an appropriately named
function), then pg_dump 7.3 should create the appropriate CREATE CAST
statements for restore into a 7.3 database.  Maybe pg_dump is missing this
for some reason?

--

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster



Fri, 24 Jun 2005 04:55:39 GMT
 pgsql-server/src/bin/pg_dump pg_backup_archiver.c

Quote:

> I'm not completely sure what the "lo" type provides, but if there was a
> cast between oid and lo in 7.2 (by having an appropriately named
> function), then pg_dump 7.3 should create the appropriate CREATE CAST
> statements for restore into a 7.3 database.  Maybe pg_dump is missing this
> for some reason?

I tried installing 7.2's contrib/lo and then running current pg_dump.
I see:

CREATE FUNCTION oid (lo) RETURNS oid
    AS '$libdir/lo', 'lo_oid'
    LANGUAGE "C";

CREATE CAST (lo AS oid) WITH FUNCTION oid (lo);

CREATE FUNCTION lo (oid) RETURNS lo
    AS '$libdir/lo', 'lo'
    LANGUAGE "C";

CREATE CAST (oid AS lo) WITH FUNCTION lo (oid);

The trouble with this is that the CREATE CASTs will fail because of the
prohibition against volatile cast functions.

I'm still of the opinion that that prohibition is inappropriate and
useless.  I'd vote for removing it.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command



Fri, 24 Jun 2005 06:53:05 GMT
 pgsql-server/src/bin/pg_dump pg_backup_archiver.c

Quote:


> >       src/bin/pg_dump: pg_backup_archiver.c

> > Log message:
> >       Adjust lo type in contrib during pg_restore so that pg_restore could
> >       reload the type.

> I find this really ugly, and I do not believe this code belongs in
> pg_dump (nor pg_restore).  We are not in the habit of putting kluges
> into pg_dump to adjust system catalog entries for version-to-version
> changes, and I certainly don't think that we should put in such a kluge
> for a type that's only contrib.

> The correct way to update contrib/lo for 7.3 is to load the 7.3
> definition into a database before restoring the old definition.

> If someone fails to do that, it'd be okay to supply this fix as a script
> in contrib/lo to run against the database after-the-fact.  But I object
> to putting it into pg_restore.

Please tell me how we avoid the failure
  ERROR:  Unable to identify an operator '=' for types 'oid' and 'lo'
          You will have to retype this query using an explicit cast
in pg_restore.

regards,
Hiroshi Inoue
        http://w2422.nsk.ne.jp/~inoue/

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster



Fri, 24 Jun 2005 13:50:46 GMT
 pgsql-server/src/bin/pg_dump pg_backup_archiver.c

Quote:

> Please tell me how we avoid the failure
>   ERROR:  Unable to identify an operator '=' for types 'oid' and 'lo'
>           You will have to retype this query using an explicit cast
> in pg_restore.

What query triggers that, exactly?

                        regards, tom lane

---------------------------(end of broadcast)---------------------------



Fri, 24 Jun 2005 13:55:11 GMT
 pgsql-server/src/bin/pg_dump pg_backup_archiver.c

Quote:


> > Please tell me how we avoid the failure
> >   ERROR:  Unable to identify an operator '=' for types 'oid' and 'lo'
> >           You will have to retype this query using an explicit cast
> > in pg_restore.

> What query triggers that, exactly?

The query made by the following code in FixupBlobRefs in pg_backup_db.c.

                /* Can't use fmtId twice in one call... */
                appendPQExpBuffer(tblQry,
                                                  "UPDATE %s SET %s =
%s.newOid"
,
                                                  tblName->data,
fmtId(attr),
                                                  BLOB_XREF_TABLE);
                appendPQExpBuffer(tblQry,
                                                  " FROM %s WHERE
%s.oldOid = %s.%s",
                                                  BLOB_XREF_TABLE,
                                                  BLOB_XREF_TABLE,
                                                  tblName->data,
fmtId(attr));

regards,
Hiroshi Inoue
        http://w2422.nsk.ne.jp/~inoue/

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Fri, 24 Jun 2005 14:20:01 GMT
 pgsql-server/src/bin/pg_dump pg_backup_archiver.c

Quote:



> Please tell me how we avoid the failure
> ERROR:  Unable to identify an operator '=' for types 'oid' and 'lo'
> You will have to retype this query using an explicit cast
> in pg_restore.

>> What query triggers that, exactly?
> The query made by the following code in FixupBlobRefs in pg_backup_db.c.

Hmmm ... does it help if we change the query to

                                                  " FROM %s WHERE
%s.oldOid = %s.%s::pg_catalog.oid",

I suspect though that the real issue is the CREATE CAST is failing;
if so, this won't help.  See my comment to Peter earlier today.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly



Fri, 24 Jun 2005 14:25:58 GMT
 pgsql-server/src/bin/pg_dump pg_backup_archiver.c

Quote:




> > Please tell me how we avoid the failure
> > ERROR:  Unable to identify an operator '=' for types 'oid' and 'lo'
> > You will have to retype this query using an explicit cast
> > in pg_restore.

> >> What query triggers that, exactly?

> > The query made by the following code in FixupBlobRefs in pg_backup_db.c.

> Hmmm ... does it help if we change the query to

>                                                   " FROM %s WHERE
> %s.oldOid = %s.%s::pg_catalog.oid",

> I suspect though that the real issue is the CREATE CAST is failing;
> if so, this won't help.  See my comment to Peter earlier today.

I know it from the first and the consideration is useless
unless we use 7.3 pg_dump.

regards,
Hiroshi Inoue
        http://w2422.nsk.ne.jp/~inoue/

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster



Fri, 24 Jun 2005 17:12:40 GMT
 
 [ 9 post ] 

 Relevant Pages 

1. pgsql-server/src/bin/pg_dump pg_backup_archiver.c

2. pgsql-server/src/bin/pg_dump pg_backup_archiver.c

3. pgsql-server/src/bin/pg_dump pg_backup_archiver.c

4. pgsql-server/src/bin/pg_dump pg_backup_archiver.c

5. pgsql/src/bin/pg_dump (pg_backup.h pg_backup_archiver.c pg_backup_archiver.h pg_backup_db.c pg_dump.c pg_restore.c)

6. pgsql/src/bin/pg_dump (common.c pg_backup_archiver.h pg_dump.c pg_dump.h)

7. pgsql/src/bin/pg_dump pg_backup_archiver.c pg_ ...

8. pgsql/src/bin/pg_dump pg_backup_archiver.c pg_ ...

9. pgsql/src/bin/pg_dump pg_backup_archiver.c pg_ ...

10. pgsql/src/bin/pg_dump pg_backup_archiver.c pg_ ...

11. pgsql/src/bin/pg_dump pg_backup_archiver.c pg_ ...

12. pgsql/src/bin/pg_dump pg_backup_archiver.c


 
Powered by phpBB® Forum Software