Return-Path: postarch Received: by postgres.Berkeley.EDU (5.61/1.29) id AA15385; Sat, 15 Feb 92 17:50:27 -0800 Message-Id: <9202160150.AA15385@postgres.Berkeley.EDU> From: postarch (Postgres Mailing Archive) Subject: Re: New user help To: postgres@postgres.berkeley.edu Sender: pg_adm@postgres.berkeley.edu Reply-To: mer@postgres.berkeley.edu In-Reply-To: Your message of "Tue, 11 Feb 92 16:59:06 GMT." <9202111835.AA29434@postgres.Berkeley.EDU> Date: Sat, 15 Feb 92 17:50:13 PST you write: > 1) text > ...however the spaces > preceding something, blue and alice are not ignored > but stored hence these instances can only be retrieved with > retrieve (word.all) where word.document[2]=" something" > not > retrieve (word.all) where word.document[2]="something" > Similarly > retrieve (manager.all) where manager.employees[2] = " alice" > succeeds whilst > retrieve (manager.all) where manager.employees[2] = "alice" > fails. The added spaces are the result of a bug in the array code. It doesn't skip white space between array elements. To avoid this problem just make sure there is no white space in your input string (it will work correctly in version 4). > A further problem with these arrays of arrays is that although > you can use manager.employees[2] in the where qualification > of a retrieve statement you cannot retrieve that array element so > > retrieve (manager.employees[2]) > > fails, although This works for me, although for reasons I don't understand it takes a long time to execute. > 2) Time Travel > > The manual pages claim Absolute Time is specified > > Month Day [Hour:Minute:Second] Year > > we can only get a time to be accepted with a full specification > including the Hour:Min:Sec part or using "now". The date parsing code will be new and improved in version 4. The input routine will be *much* more flexible than before, and some of the problems outlined in previous mailings will be eliminated. Unfortunately some flexibility will be lost. Currently you can specify times from 1902 to 2038 and with the new code the earliest date will be Jan 1 1970. > However when quering versions of classes only the date part > of the time appears to be used. > Therefore when we attempted historical queries we got empty > classes only to retry the queries the next day and find that they > did work! > So is the current granularity of time one day ? > We also found that versions created using "now" were not snapshots > that did not have updates propagated from the base class as suggested > in "The POSTGRES Data Model" but acted like other versions with > updates from the base class propagated to the version. The time specifications for versions do not work. When version 3 went out the query rewrite system was completely rewritten and in the nick of time versions were made to work using the new system. Unfortunately we didn't have time to add time stamping. I will put it on the "hopefully get it done before version 4 release date" queue. > Also the syntax from the User Manual > > retrieve (EMP.salary) using EMP[T] where EMP.name ="Sam" > > doesnt work although > > retrieve (e.salary) using e in EMP[T] where e.name ="sam" > > does. I believe the manual syntax is wrong here. The way to specify time ranges is in the from clause. Whenever I try to use the keyword 'using' in this context I get a syntax error from the parser. After some tests I find that both of the following work: retrieve (EMP.salary) from EMP in EMP[T] and retrieve (e.salary) from e in EMP[T] > 3) Transitive closure > > In a number of places eg Postgres Next-Generation Database > Management System oct 91 Comm ACM it is suggested that you > can explode a parts or ancestor hierachy using a retrieve* syntax > e.g. > > retrieve* into answer (parent.older) from a in answer > wher parent.younger = "John" or parent.younger = a.older > > We cannot get queries like this to work are we doing something wrong? > Is there an alternative ? You cannot do these queries in the current implementation. Recursive queries were added a few releases ago, but due to implementation problems they were removed from the system. Jeff Meredith mer@postgres.berkeley.edu p.s. The scheduled release date for version 4 is March 1st.