From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Doug McNaught <doug(at)mcnaught(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: contrib/lo and restoring databases |
Date: | 2003-03-14 17:11:09 |
Message-ID: | 21945.1047661869@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Doug McNaught <doug(at)mcnaught(dot)org> writes:
> pg_restore: creating CAST oid (public.lo)
> pg_restore: [archiver (db)] could not execute query: ERROR: parser: parse error at or near "." at character 132
> pg_restore: *** aborted because of error
> This looks like a bug in pg_dump or pg_restore to me.
No, I think the command is perfectly reasonable; the problem is the
backend parser isn't prepared for a qualified typename in CREATE CAST.
This is a bug that's fixed in CVS:
2003-02-05 15:16 tgl
* src/backend/parser/gram.y (REL7_3_STABLE): Allow qualified type
names in CREATE CAST, DROP CAST. Also allow the construction
'SETOF type[]' which for some reason was previously overlooked
(you'd have to name the array type directly to make it work).
It'll be in 7.3.3. In the meantime you could possibly grab the updated
gram.y from the CVS server, or just not restore the CAST from the dump.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | tom dyson | 2003-03-14 17:15:22 | PostgreSQL and XML |
Previous Message | Tom Lane | 2003-03-14 17:04:55 | Re: Automake |