Re: [HACKERS] v6.4 - What is planned...?

> > We do have in the TODO list:
> >
> >         A dash(-) marks changes to be in the next release.
> >
> > and appears to be fairly accurate.  Haven't hear much about people
> > claiming items for 6.4 yet.
> >
>
> Bruce,
> Item "Remove restriction that ORDER BY field must be in SELECT list",  in the
> TODO list, has been completed.

Dash added to TODO.  Gee, I could swear I marked that as complete
already.  Strange.

>
> Stephan or Anyone,
> What is the status of the HAVING clause?   I noticed that it almost made the
> 6.3.2 cut, but I haven't heard any thing for a while.  I would really like to
> see this feature implemented.   It is important to my user community.

It works, but has some bugs, so we dis-abled it in gram.y until it was
working perfectly.  I can forward the bug reports if you wish.  Stephan
was working on it, but I haven't heard anything from him in months.  You
are welcome to fix it.

>
> Everyone especially Vadim,
> I agree with Marc.   Row locking is huge.  In my user community, it is
> unacceptable to wait for up to 30 minutes (or even one minute) for a report to
> finish so that a users can commit an invoice or commit a change to a customer
> attribute.   I can deal with it for now because my databases are batch loaded
> for reporting purposes only.  However, I plan to go forward with some pretty
> important projects that assume that record/page locking will exist within the
> next 12 month or so.   Am I being too presumptuous?

Sounds like you need dirty read rather than row locking. If they lock a
row or the entire table, it still would cause the program to stall.  I
am not saying you don't need row or page locking, just that this may not
help even if we had it.

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)