We are preparing to upgrade to 8.1 from 7.4 Postrgres. In this case, it is a Red Hat
Linux server. Using the 8.1.4 pg_dumpall, pointed at the 7.4 instance, we get the
following errors.

Anyone know why?

Naomi



/applications/pgsql/8.1.4/bin/pg_dumpall --
-- PostgreSQL database cluster dump
--

\connect postgres

--
-- Roles
--

CREATE ROLE "";
ALTER ROLE "" WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN;
pg_dumpall: query failed: ERROR: type "e" does not exist
pg_dumpall: query was: SELECT useconfig[1] FROM pg_shadow WHERE usename = E'\003'


--
----------------------------------------------------------------------------
Naomi Walker Chief Information Officer
Eldorado Computing, Inc. nwalker@eldocomp.com 602-604-3100
----------------------------------------------------------------------------
Far and away the best prize that life offers is the chance to work hard at
work worth doing. - Theodore Roosevelt
----------------------------------------------------------------------------

-- CONFIDENTIALITY NOTICE --

Information transmitted by thisÂ*e-mail is proprietary to MphasiS and/or its Customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that isÂ*privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this e-mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailmaster@mphasis.com and delete this mail from your records.

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Naomi Walker wrote:
> We are preparing to upgrade to 8.1 from 7.4 Postrgres. In this case, it is a Red Hat
> Linux server. Using the 8.1.4 pg_dumpall, pointed at the 7.4 instance, we get the
> following errors.

What are the exact options? I tried to reproduce it here, using a 8.1
and 8.2 pg_dumpall, and a 7.4 server, and couldn't.

> CREATE ROLE "";
> ALTER ROLE "" WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN;

This is weird anyway -- do you really have a role named "" (empty
string)?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Alvaro Herrera <alvherre@commandprompt.com> writes:
> What are the exact options? I tried to reproduce it here, using a 8.1
> and 8.2 pg_dumpall, and a 7.4 server, and couldn't.

>> CREATE ROLE "";
>> ALTER ROLE "" WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN;

> This is weird anyway -- do you really have a role named "" (empty
> string)?

It's not "empty string", it's '\003' as shown by the failure:

query was: SELECT useconfig[1] FROM pg_shadow WHERE usename = E'\003'

The problem is evidently that appendStringLiteral tries to use E syntax
in an inappropriate context, ie, while talking to a server that doesn't
understand it. This is fixed in HEAD (by using appendStringLiteralConn)
but I'm not sure if there is any very good way to fix it in the back
branches.

In the short term, Naomi's best workaround is surely to drop or rename
that user ... it hardly seems likely that the name is anything but a
typo.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly