Resent-From: POSTGRES mailing list <postman@postgres.Berkeley.EDU>
Resent-Message-Id: <199410250627.XAA03129@nobozo.CS.Berkeley.EDU>
Sender: owner-postman@postgres.Berkeley.EDU
Message-ID: <Eif_J_i00hMd8ZKG5w@cs.cmu.edu>
Date: Tue, 25 Oct 1994 02:27:22 -0400 (EDT)
From: Robert.Patrick@cs.cmu.edu
To: postgres@postgres.Berkeley.EDU
Subject: Postgres Gets Confused!
Resent-To: postgres-redist@postgres.Berkeley.EDU
Resent-Date: Mon, 24 Oct 94 23:27:55 -0700
Resent-XMts: smtp

We are using Postgres to store the data for our information modeling
program.  In doing this, each user has his own PGDATA directory which is
served by his own postmaster (obviously running on different ports).  

The problem we keep seeing is that, after using the database
successfully for a period of time, Postgres seems to get confused and do
one of the following: 

1.) Claims the user is not a valid user even though they have been using
the system not 5 minutes before. 

2.) Claims the database does not exist even though they had been using
it not 5 minutes earlier and it is still listed under the base
subdirectory. 

Most of the time, I can cure this problem by logging in removing the
user and re-adding them.  Unfortunately, this does not always work and
we have had to destroy the PGDATA directory and recreate it from
scratch.  Which is definitely not desirable since it's not too useful
for a user to store their information in our system just to have it
destroyed because Postgres gets confused. 

Also, there seems to be a bug in the parser/planner.  First, it tells me
that I must use an explicit cast (see below), which makes perfect sense.
 Then, I use an explicit cast and it tells me that I cannot do cast this
expression (huh?).  Then, I rewrite the query to include another field
in the where clause, along with the EXACT same field that I tried to
cast in the previous query (which Postgres said I couldn't do) and it
works as expected. 


 paneer> monitor 
Welcome to the POSTGRES terminal monitor 

Go 
* retrieve (pg_operator.oprname) where pg_operator.oprleft = 16\g 

Query sent to backend is "retrieve (pg_operator.oprname) where
pg_operator.oprleft = 16" 
NOTICE:Oct 25 02:09:05:there is no operator = for types oid and int4 
NOTICE:Oct 25 02:09:05:You will either have to retype this query using an 
NOTICE:Oct 25 02:09:05:explicit cast, or you will have to define the operator 
WARN:Oct 25 02:09:05:= for oid and int4 using DEFINE OPERATOR 

Go 
* retrieve (pg_operator.oprname) where pg_operator.oprleft = 16::oid\g 

Query sent to backend is "retrieve (pg_operator.oprname) where
pg_operator.oprleft = 16::oid" 
WARN:Oct 25 02:09:17:parser_typecast: cannot cast this expression to
type "oid" 

Go 
* retrieve (pg_operator.oprname) where pg_operator.oprname = "<" and
pg_operator.oprleft = 16::oid\g 

Query sent to backend is "retrieve (pg_operator.oprname) where
pg_operator.oprname = "<" and pg_operator.oprleft = 16::oid" 
--------------- 
| oprname     | 
--------------- 
| <           | 
--------------- 

Go 
* 

Looks like a bug(s) to me, don't you think? 
Robert 

P.S.  I'm running Version 4.2 with all of the latest patches on OSF/1
1.3, OSF/1 2.0, HP-UX 9.03, SunOS 4.13, and Ultrix 4.2a.   All platforms
experience the same problems! 

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU"

   If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================