Thread: ERROR: did not find '}' at end of input node (again)
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)
Andrei Ivanov <andrei.ivanov@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
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?
"John Sidney-Woollett" <johnsw@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/current/static/ddl-schemas.html not cover the same ground that's in the 7.3 docs? regards, tom lane
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" <johnsw@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/current/static/ddl-schemas.html > not cover the same ground that's in the 7.3 docs? > > regards, tom lane >
The ouput is attached... On Thu, 11 Dec 2003, Tom Lane wrote: > Andrei Ivanov <andrei.ivanov@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 >
Attachment
Andrei Ivanov <andrei.ivanov@ines.ro> writes:
> On Thu, 11 Dec 2003, Tom Lane wrote:
>> Andrei Ivanov <andrei.ivanov@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
Andrei Ivanov <andrei.ivanov@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
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 <andrei.ivanov@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 >