I think there is a problem with the syntax -- highlighted below
It seems that
datname NOT in (datname='blah')
should just be
datname NOT in ('blah')
SELECT db.oid, datname, db.dattablespace AS spcoid, spcname, datallowconn,
datconfig, datacl, pg_encoding_to_char(encoding) AS serverencoding,
p
Thank you for your quick response.
There are a few things this brings up:
1. The pgAdmin help file states the use of datname IN ('blah') in the DB
Restriction field
2. Most people know which databases they want to connect to. Wouldn't it make
more sense to use datename IN (...) rather than NO
Zach Conrad a écrit :
DB Restriction field borks on datname IN ('blah') or datname='blah' with the error:
"ERROR: operator does not exist: name <> boolean LINE 5: WHERE datname NOT IN
(datname='blah')
Here's the full query from the logs being sent from pgAdmin:
SELECT db.oid, datname, db.dat
DB Restriction field borks on datname IN ('blah') or datname='blah' with the
error: "ERROR: operator does not exist: name <> boolean LINE 5: WHERE datname
NOT IN (datname='blah')
Here's the full query from the logs being sent from pgAdmin:
SELECT db.oid, datname, db.dattablespace AS spcoid, sp
True...I pointed to a link.
Now I point to the /usr/lib/postgresql/8.3/bin/ where the real file is
but no restore active. A database node was selected. G
I manage to restore the database using directly the pg_retore command,
but I would like to have the pgadmin doing this...
Simone
The pgAdmin Development Team are pleased to announce the release of
pgAdmin 1.8.4, the Open Source graphical PostgreSQL administration tool
for Windows, Linux, FreeBSD, Mac OS X and Solaris, now available for
download in source and a variety of binary formats from:
http://www.pgadmin.org/down
On Thu, Jun 5, 2008 at 10:24 AM, Raymond O'Donnell <[EMAIL PROTECTED]> wrote:
> On 05/06/2008 10:17, Simone Gadenz wrote:
>
>> Raymond, it was set correctly to /usr/bin/ where the executables are.
>
> Are they really in /usr/bin/, as opposed to /usr/local/pgsql/bin/ (or some
> variation thereon...)
On 05/06/2008 10:17, Simone Gadenz wrote:
Raymond, it was set correctly to /usr/bin/ where the executables are.
Are they really in /usr/bin/, as opposed to /usr/local/pgsql/bin/ (or
some variation thereon...)? - not questioning your ability to read :-)
but AFAIK the PG executables usually ge
On 05/06/2008 10:20, Dave Page wrote:
On Thu, Jun 5, 2008 at 10:16 AM, Raymond O'Donnell <[EMAIL PROTECTED]> wrote:
I thought that odd-numbered versions were development versions, while the
even-numbered ones were releasesor did I miss-hear at some point? :-)
Thats the middle number. 1.8.x
On Thu, Jun 5, 2008 at 10:16 AM, Raymond O'Donnell <[EMAIL PROTECTED]> wrote:
> On 05/06/2008 01:23, Erwin Brandstetter wrote:
>
>> As I said: upcoming release. (1.8.3 was skipped because of a bug.)
>
> I thought that odd-numbered versions were development versions, while the
> even-numbered ones w
Raymond, it was set correctly to /usr/bin/ where the executables are.
Under tools only the backup is actve...not the restore.
Tks
S.
Raymond O'Donnell ha scritto:
On 04/06/2008 21:12, Simone Gadenz wrote:
I try to import a db dumped on another machine but I cannot have the
restore command a
On 05/06/2008 01:23, Erwin Brandstetter wrote:
As I said: upcoming release. (1.8.3 was skipped because of a bug.)
I thought that odd-numbered versions were development versions, while
the even-numbered ones were releasesor did I miss-hear at some
point? :-)
Ray.
--
12 matches
Mail list logo
