Re: [BUGS] Bug #869: varchar 's comparision

2003-01-09 Thread Tom Lane
[EMAIL PROTECTED] writes: >M_ID VARCHAR(10) M_DESCVARCHAR(10) > --- >ABC HELLO > UPDATE MYTABLE SET M_DESC='GOOD' WHERE M_ID='ABC ' AND M_DESC='HELLO ' > UPDATE 0 RE

Re: [BUGS] Bug #869: varchar 's comparision

2003-01-09 Thread Stephan Szabo
On Thu, 9 Jan 2003 [EMAIL PROTECTED] wrote: > trainee ([EMAIL PROTECTED]) reports a bug with a severity of 2 > The lower the number the more severe it is. > > Short Description > varchar 's comparision > > Long Description > SERVER: PGSQL 7.31 + MANDRAKE LINUX 8.1 > CLIENT: VISIVAL FOXPRO 7.0 +

[BUGS] Bug #869: varchar 's comparision

2003-01-09 Thread pgsql-bugs
trainee ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description varchar 's comparision Long Description SERVER: PGSQL 7.31 + MANDRAKE LINUX 8.1 CLIENT: VISIVAL FOXPRO 7.0 + PGSQLODBC 7.02 TABLE :MYTABLE M_ID VARCHAR(1

Re: [BUGS] Libpq is not a shared library on Mac OS X

2003-01-09 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> writes: > One thing I like about the patch is that it introduces a differentiation > between run-time loadable modules and build-time linkable libraries, which > is something I've wanted to do for a while. Even on platforms where this > isn't technically necess

Re: [BUGS] Libpq is not a shared library on Mac OS X

2003-01-09 Thread Peter Eisentraut
Tom Lane writes: > I will test and apply the parts that are related to OS X shared library > behavior. If Benjamin wants to advocate the other stuff (like pam.h > search path) that should be handled as separate patches. One thing I like about the patch is that it introduces a differentiation bet

Re: [BUGS] dropping user doesn't erase his rights.

2003-01-09 Thread Hubert depesz Lubaczewski
On Thu, Jan 09, 2003 at 11:21:56AM -0500, Tom Lane wrote: > Difficult to do, when those privileges might be recorded in databases > you're not even connected to at the time of the drop. I belive it would be pretty difficult, but leaving it "just like that" creates ssecurity breach (imagine someone

Re: [BUGS] dropping user doesn't erase his rights.

2003-01-09 Thread Tom Lane
Hubert depesz Lubaczewski <[EMAIL PROTECTED]> writes: > I belive drop user should automatically drop all user privileges Difficult to do, when those privileges might be recorded in databases you're not even connected to at the time of the drop. regards, tom lane -

[BUGS] dropping user doesn't erase his rights.

2003-01-09 Thread Hubert depesz Lubaczewski
Versions tested: 7.4devel from cvs and 7.2.x (i'm not sure about x since the test was done by somebody else). Description: When dropping user his rights stay in database creating possible security breach. Sample Code: create table xxx (...); create user test; grant select on xxx to te

Re: [BUGS] Version 7.2.3 unrecoverable crash on missing pg_clog

2003-01-09 Thread Andy Osborne
Tom Lane wrote: Andy Osborne <[EMAIL PROTECTED]> writes: Tom Lane wrote: > But with no way to reproduce it it's hard to pin blame. Sad but true :-( You didn't happen to make a physical copy of the news table before dropping it, did you? It'd be interesting to examine the remains. Sad

Re: [BUGS] Version 7.2.3 unrecoverable crash on missing pg_clog

2003-01-09 Thread Tom Lane
Andy Osborne <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >>> FATAL 2: open of /u0/pgdata/pg_clog/0726 failed: No such file or directory >> What range of file names do you actually see in pg_clog? > Currently to 00D6. I don't know what it was last night. Not any greater, for sure. (FYI, e

Re: [BUGS] Version 7.2.3 unrecoverable crash on missing pg_clog

2003-01-09 Thread Andy Osborne
Tom Lane wrote: Andy Osborne <[EMAIL PROTECTED]> writes: One of our databases crashed yesterday with a bug that looks a lot like the non superuser vacuum issue that 7.2.3 was intended to fix, although we do our vacuum with a user that has usesuper=t in pg_user so I guess it's not that simple.

Re: [BUGS] Version 7.2.3 unrecoverable crash on missing pg_clog

2003-01-09 Thread Tom Lane
Andy Osborne <[EMAIL PROTECTED]> writes: > One of our databases crashed yesterday with a bug that looks > a lot like the non superuser vacuum issue that 7.2.3 was > intended to fix, although we do our vacuum with a user that > has usesuper=t in pg_user so I guess it's not that simple. > FATAL 2:

Re: [BUGS] Bug #868: temp schema can't be clean automatically

2003-01-09 Thread Tom Lane
[EMAIL PROTECTED] writes: > So my database remain several temporary schema, I don't know why? Because it's designed to work that way. What's the point of dropping the schema entry, only to have to recreate it later? regards, tom lane ---(end of br

[BUGS] Version 7.2.3 unrecoverable crash on missing pg_clog

2003-01-09 Thread Andy Osborne
All, One of our databases crashed yesterday with a bug that looks a lot like the non superuser vacuum issue that 7.2.3 was intended to fix, although we do our vacuum with a user that has usesuper=t in pg_user so I guess it's not that simple. From the logs: DEBUG: pq_recvbuf: unexpected EOF on c

[BUGS] Bug #868: temp schema can't be clean automatically

2003-01-09 Thread pgsql-bugs
trainee ([EMAIL PROTECTED]) reports a bug with a severity of 3 The lower the number the more severe it is. Short Description temp schema can't be clean automatically Long Description postgresql 7.31 + mandrake linux 8.1 when I create a temporary table, server will create temporary schema pg_te