You need a newer pgadmin --- pg_database.datpath went away in 8.0.
I'm installing the new version. Thanks.
---(end of broadcast)---
TIP 8: explain analyze is your friend
PFC <[EMAIL PROTECTED]> writes:
> ERREUR: 42703: la colonne <> n'existe pas
> EMPLACEMENT : transformColumnRef, parse_expr.c:1099
> Do you know if this is normal, should this column exist, is it a
> problem
> with pgadmin ?
You need a newer pgadmin --- pg_database.datpath went away in
pgadmin3 does this (from pg's log with level set at debug5):
INSTRUCTION : SELECT db.oid, datname, datpath, datallowconn, datconfig,
datacl, pg_encoding_to_char(encoding) AS serverencoding,
pg_get_userbyid(datdba) AS datowner,has_database_privilege(db.oid,
'CREATE') as cancreate
Sometimes life has an irony of itself.
Today I modified some of my gentoo USE flags for something totally
unrelated to postgres.
Tonight I built postgres in debug mode : the offending query worked.
I thught "hm."
I rebuilt it without debug, and it still works.
I don't know what made it NOT
PFC <[EMAIL PROTECTED]> writes:
> I have no idea what to type in gbd to get the trace, though
What I usually do is
- start a psql session
- in another window, find out the PID of the backend attached
to the psql session, and do
$ gdb /path/to/postgres backend_PID
...
If you want, you can try building with --enable-debug and getting a gdb
traceback from the call to errfinish(). That would at least give us
some clue where in the rule text it's getting confused.
Is this :
./configure --enable-debug
?
I have no idea what to type in gbd to get
PFC <[EMAIL PROTECTED]> writes:
>> You might try comparing the results of
>> select ev_action from pg_rewrite where ev_class = 'pg_user'::regclass;
>> from the two builds.
> I'll spare your eyes and tell you right away that the results are
> identical... they're at the bottom of the email.
You might try comparing the results of
select ev_action from pg_rewrite where ev_class = 'pg_user'::regclass;
from the two builds.
regards, tom lane
Well...
I'll spare your eyes and tell you right away that the results are
identical... they're at the bottom of the
PFC <[EMAIL PROTECTED]> writes:
>> Hmm; the only occurrence of that string in the sources is in
>> nodes/read.c, which AFAIK would never be invoked for a query entered
>> straight from the client. What could trigger it would be trying to
>> read a rule that is misformatted for some reason. Maybe
Hmm; the only occurrence of that string in the sources is in
nodes/read.c, which AFAIK would never be invoked for a query entered
straight from the client. What could trigger it would be trying to
read a rule that is misformatted for some reason. Maybe you have
a damaged pg_user view definition
PFC <[EMAIL PROTECTED]> writes:
> I've traced it to the following query to get information about the
> database :
> SELECT pdb.datname AS datname, pu.usename AS datowner,
> pg_encoding_to_char(encoding) AS datencoding,
> (SELECT description FROM pg_description pd WHERE pdb.oid=pd.objoid)
Why don't you try PG Lightning Admin and see if you get the same error.
http://www.amsoftwaredesign.com
I have been using it with 8.01 without issues.
T
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives
Hello,
Just installed pg 8.0.1-r3 and now phppgadmin and pgadmin3 die with a
cryptic error message.
I've traced it to the following query to get information about the
database :
SELECT pdb.datname AS datname, pu.usename AS datowner,
pg_encoding_to_char(encoding) AS datencoding,
(SE
13 matches
Mail list logo
