On Wed, May 11, 2005 at 11:35:16PM -0600, Sankaran Anupama wrote:
>
> I find that while pg_dump and pg_restore take/read the password from
> the .pgpass file, dropdb and createdb do not. For these, i'm still
> having to key in the password. The permissions for the .pgpass is 0600
> as expected.
Us
Hello,
two last questions about the transaction ID wraparound problem of my DBs I had
yesterday (see former postings). After applying the 'recovery procedure' Tom
suggested now my XIDs are looking almost fine again, except for the template0
DB.
dev_db=# SELECT datname, age(datfrozenxid) FROM pg_d
On Wed, May 11, 2005 at 01:36:00PM +0100, İbrahim wrote:
>
> i m using pg 8.0.2 in a project with Visual Studio.NET at Windows Platform
> but when i send a null value to my Prmary Key column it accepts that value.
PRIMARY KEY implies NOT NULL. Are you sure the value being inserted
is NULL and no
Thanks for the response.
The following are versions I checked:
postgres, createdb, dropdb, pg_dump and pg_restore - 7.4.7
I did an ldd for each of createdb, dropdb, pg_dump and pg_restore. The
output was - /usr/lib/libpq.so.3 for all of them.
All these have been linked with the same libpq libra
"Michael Beckstette" <[EMAIL PROTECTED]> writes:
> two last questions about the transaction ID wraparound problem of my DBs I had
> yesterday (see former postings). After applying the 'recovery procedure' Tom
> suggested now my XIDs are looking almost fine again, except for the template0
> DB.
You
"Celia McInnis" <[EMAIL PROTECTED]> writes:
> select 949::bit(10) gives 1110110101 (as expected).
> select 949::bit(10)::bit(3) gives 111 (the 3 most significant bits)
> select 949::bit(3) gives 101 (the 3 least significant bits).
> As a mathematician, I'd certainly at least want the last two sele
"Sankaran Anupama" <[EMAIL PROTECTED]> writes:
> Thanks for the response.
> The following are versions I checked:
> postgres, createdb, dropdb, pg_dump and pg_restore - 7.4.7
I just tried it here, and 7.4.8 createdb definitely picks up .pgpass
for me. It seems like you must have some local breaka
Problem with ROW types in UNION.
1. UNION of ROW types fails with operator error.
create type addrs as (
addr text,
citytext,
state char(2),
zip text);
--
-- UNION of ROWS doesn't work (simply wrong)
--
select ROW('4514 Cherry St','Oakland','CA','94666')
On Thu, May 12, 2005 at 12:32:48PM -0700, elein wrote:
> --
> -- UNION of ROWS doesn't work (simply wrong)
> --
> select ROW('4514 Cherry St','Oakland','CA','94666')::addrs
> UNION
> select ROW('4515 Cherry St','Oakland','CA','94666')::addrs;
> -- ERROR: could not identify an ordering operator fo
On Thu, May 12, 2005 at 03:57:18PM -0400, Alvaro Herrera wrote:
> On Thu, May 12, 2005 at 12:32:48PM -0700, elein wrote:
>
> > --
> > -- UNION of ROWS doesn't work (simply wrong)
> > --
> > select ROW('4514 Cherry St','Oakland','CA','94666')::addrs
> > UNION
> > select ROW('4515 Cherry St','Oaklan
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think you could create a btree operator class to make it all work.
Hm. Given that we've managed to build a general opclass for arrays,
I suppose it should be possible for records too. Hardly trivial though.
A closely related point is fixing row com
On a Sun ultra2 sparc64 initdb hangs here:
$ initdb -D /usr/local/pgsql/data
The files belonging to this database system will be owned by user "pgsql".
This user must also own the server process.
The database cluster will be initialized with locale C.
creating directory /usr/local/pgsql/data ...
David Walker <[EMAIL PROTECTED]> writes:
> On a Sun ultra2 sparc64 initdb hangs here:
Where's "here"? Build with --enable-debug, then attach to the stuck
process with gdb and get a stack trace.
regards, tom lane
---(end of broadcast)--
13 matches
Mail list logo
