ERROR: did not find '}' at end of input node (again)

[Andrei Ivanov]

This happend again, but now, postgresql tells me where it happens:

pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: did not find '}' at end of
input node
pg_dump: The command was: select (select usename from pg_user where
usesysid = datdba) as dba, pg_encoding_to_char(encoding) as encoding,
datpath from pg_database where datname = 'dc'
pg_dumpall: pg_dump failed on database "dc", exiting
template1=# select usename from pg_user;
ERROR: did not find '}' at end of input node
\d pg_user
********* QUERY **********
SELECT c.oid,
n.nspname,
c.relname
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE pg_catalog.pg_table_is_visible(c.oid)
AND c.relname ~ '^pg_user$'
ORDER BY 2, 3;
**************************

********* QUERY **********
SELECT relhasindex, relkind, relchecks, reltriggers, relhasrules
FROM pg_catalog.pg_class WHERE oid = '16683'
**************************

********* QUERY **********
SELECT a.attname,
pg_catalog.format_type(a.atttypid, a.atttypmod),
(SELECT substring(d.adsrc for 128) FROM pg_catalog.pg_attrdef d
WHERE d.adrelid = a.attrelid AND d.adnum = a.attnum AND a.atthasdef),
a.attnotnull, a.attnum
FROM pg_catalog.pg_attribute a
WHERE a.attrelid = '16683' AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum
**************************

********* QUERY **********
SELECT pg_catalog.pg_get_viewdef('16683'::pg_catalog.oid, true)
**************************

ERROR: did not find '}' at end of input node
I think (hope) I can save the data by copying the data on another computer
and start postgresql there and then dump it (just like I did last time).

The problem is, why does this happen and how can I prevent it ? Maybe this
is caused by an unproper shutdown of postgresql ?

SELECT VERSION();
version
------------------------------------------------------------------------------------------------------------------
PostgreSQL 7.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.2 20031022 (Gentoo Linux 3.3.2-r2, propolice)
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Tom Lane]

Andrei Ivanov <an***********@ines.ro> writes:

template1=# select usename from pg_user;
ERROR: did not find '}' at end of input node

There's something wrong with the ON SELECT rule for the pg_user view,
evidently. Could we see the output of

select * from pg_rewrite where ev_class = 16683;

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[John Sidney-Woollett]

I'm slightly confused by schemas and search paths...

I'm using Postgres 7.4, and have broken my original test database into
various schemas now. Using google I found a reference to a 7.3 document
that provided quite a lot of information on schemas (in the section on SQL
syntax).

It appears that by default, the search path is a schema the same as your
login name, and then public.

I have created the schema in a database as the postgres user, and also
created all that schema's objects (as the postgres user).

Later I will connect to the schema via another user (say 'FRED') (who will
have appropriate access rights to the objects in the schema).

Question 1
==========
Is there a way to set the default search path for the user 'FRED'
permanently? Or do you have to reset the search path (and/or default
schema) for each new session?

Question 2
==========
If I am the postgres user and creating a function (for example) in a given
schema, do I have to qualify ALL the objects referred to in the function
by the schema prefix (if I don't want them in the public schema)?

And if I use the "SET search_path TO schema" command, am I still required
to be explicit about the schema name for objects referred to in a newly
created function?

Thanks for shedding any light on the above.

John Sidney-Woollett

ps Is the 7.4 documentation less detailed on schemas than the 7.3 docs? Or
have I missed a section somewhere?

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Tom Lane]

"John Sidney-Woollett" <jo****@wardbrook.com> writes:

Is there a way to set the default search path for the user 'FRED'
permanently?
See ALTER USER. You can set per-user or per-database defaults for any
SETtable variable, not only search_path.
If I am the postgres user and creating a function (for example) in a given
schema, do I have to qualify ALL the objects referred to in the function
by the schema prefix (if I don't want them in the public schema)?
It's a good idea. At the moment a function body is interpreted with the
call-time value of search_path. We've batted around the idea that it
should use the creation-time path, but nothing's been done about it.
ps Is the 7.4 documentation less detailed on schemas than the 7.3
docs?

I don't believe we've removed anything; rearranged, perhaps. Does
http://www.postgresql.org/docs/curre...l-schemas.html
not cover the same ground that's in the 7.3 docs?

regards, tom lane

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

[John Sidney-Woollett]

Thanks Tom, that's cleared up both issues.

You're right about the docs - I couldn't find the material in the 7.4 docs
because I wasn't sure where to look.

A full text index (web app showcasing Postgres's full test search
capabilities) of the latest docs would be great! ... please don't say
"google" :)

Thanks for your help.

John

Tom Lane said:

"John Sidney-Woollett" <jo****@wardbrook.com> writes:

Is there a way to set the default search path for the user 'FRED'
permanently?

See ALTER USER. You can set per-user or per-database defaults for any
SETtable variable, not only search_path.

If I am the postgres user and creating a function (for example) in a
given
schema, do I have to qualify ALL the objects referred to in the function
by the schema prefix (if I don't want them in the public schema)?

It's a good idea. At the moment a function body is interpreted with the
call-time value of search_path. We've batted around the idea that it
should use the creation-time path, but nothing's been done about it.

ps Is the 7.4 documentation less detailed on schemas than the 7.3
docs?

I don't believe we've removed anything; rearranged, perhaps. Does
http://www.postgresql.org/docs/curre...l-schemas.html
not cover the same ground that's in the 7.3 docs?

regards, tom lane

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

http://www.postgresql.org/docs/faqs/FAQ.html

[Tom Lane]

Andrei Ivanov <an***********@ines.ro> writes:

On Thu, 11 Dec 2003, Tom Lane wrote:

Andrei Ivanov <an***********@ines.ro> writes:

template1=# select usename from pg_user;
ERROR: did not find '}' at end of input node
There's something wrong with the ON SELECT rule for the pg_user view,
evidently. Could we see the output of

select * from pg_rewrite where ev_class = 16683;

The ouput is attached...

Well, that's interesting, because it's no different from what I get.
So it seems the fault is not in your database but in the rule-reading
routines. Are you sure you have a clean build of PG 7.4? I'm wondering
about having a slightly out-of-sync version that's expecting slightly
different contents of the rule structures. We make such changes
regularly, but they're supposed to go along with catversion.h changes
that prevent you from running the wrong server version against a
database ...

regards, tom lane

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

http://www.postgresql.org/docs/faqs/FAQ.html

[Tom Lane]

Andrei Ivanov <an***********@ines.ro> writes:

It's an almost clean build (it has
http://gppl.terminal.ru/hier-Pg7.4-0.3.tar.gz in it)...

That's your problem, then; it makes incompatible changes in stored
rules. The patch should have included a catversion.h change to force
you to initdb after applying it.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

[Andrei Ivanov]

I've recompiled without the patch and all is fine now. I'm sorry for
waisting your time...
On Thu, 11 Dec 2003, Tom Lane wrote:

Andrei Ivanov <an***********@ines.ro> writes:

It's an almost clean build (it has
http://gppl.terminal.ru/hier-Pg7.4-0.3.tar.gz in it)...

That's your problem, then; it makes incompatible changes in stored
rules. The patch should have included a catversion.h change to force
you to initdb after applying it.

regards, tom lane

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