Re: [HACKERS] Open 6.4 items

Here they are. I know people want the 6.4 feature list.

---------------------------------------------------------------------------

cidr/IP address type
change pg args for platforms that don't support argv changes
(setproctitle()?, sendmail hack?)
fix problem when DEFAULT string for CHAR() is not same as column
have psql dump out rules text with new function
cnf-ify still can exhaust memory
permissions on indexes: what do they do? should it be prevented?
man pages/sgml synchronization (dump out man pages as postscript?)
remove PARSEDEBUG defines if not longer needed
low level locking - status?
improve reporting of syntax errors by showing location of error in query
use index with constants on functions
allow chainging of pages to allow >8k tuples
SELECT oid @ oid @ oid FROM pg_user fails with parser error, not function error
document/trigger/rule so changes to pg_shadow create pg_pwd
large objects orphanage
improve group handling

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)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)

On Sat, 29 Aug 1998, Bruce Momjian wrote:

> Here they are. I know people want the 6.4 feature list.
>
> ---------------------------------------------------------------------------
>
> cidr/IP address type
> change pg args for platforms that don't support argv changes
> (setproctitle()?, sendmail hack?)
> fix problem when DEFAULT string for CHAR() is not same as column
> have psql dump out rules text with new function
> cnf-ify still can exhaust memory
> permissions on indexes: what do they do? should it be prevented?
> man pages/sgml synchronization (dump out man pages as postscript?)
> remove PARSEDEBUG defines if not longer needed
> low level locking - status?
> improve reporting of syntax errors by showing location of error in query
> use index with constants on functions
> allow chainging of pages to allow >8k tuples
> SELECT oid @ oid @ oid FROM pg_user fails with parser error, not function error
> document/trigger/rule so changes to pg_shadow create pg_pwd

> large objects orphanage

I'm working on orphans at the moment, should have something to commit
later today...

> improve group handling
>
> --
> Bruce Momjian | 830 Blythe Avenue
> maillist(at)candle(dot)pha(dot)pa(dot)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)
>

--
Peter T Mount peter(at)retep(dot)org(dot)uk
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
Java PDF Generator: http://www.retep.org.uk/pdf

Vadim Mikheev wrote:

> >
> > example:
> > select upper(usename), count(usename) from pg_shadow group by 1;
> > OK
> > select upper(usename), count(oid) from pg_shadow group by 1;
> > CRASH
> >
> > It did work in 6.3.
>
> As I remember, someone re-implemented GroupBy node in 6.4...

You may be referring to me. I made some changes to the SortGroupBy parse
node to allow espressions. I didn't touch the GroupClause node. Also,
I think this bug arrived before I made my changes in 6.4

Vadim Mikheev wrote:

> Bruce Momjian wrote:
> >
> > low level locking - status?
>
> Work in progress -:))
> This is 6.5 item...
>
> But this is 6.4 item from TODO:
> * select upper(usename), count(usesysid) from pg_shadow group by 1;
> --> CRASH
>
> - group by function is BROKEN!!!
>
> Is anybody working on fix ?
>

Not I, but I can give you some background. The crash seems to only
occur when the argument of the GROUPed by function is not used elsewhere
in the target list.

example:
select upper(usename), count(usename) from pg_shadow group by 1;
OK
select upper(usename), count(oid) from pg_shadow group by 1;
CRASH

It did work in 6.3.

Bruce Momjian wrote:
>
> low level locking - status?

Work in progress -:))
This is 6.5 item...

But this is 6.4 item from TODO:
* select upper(usename), count(usesysid) from pg_shadow group by 1;
--> CRASH

- group by function is BROKEN!!!

Is anybody working on fix ?

Vadim

David Hartwig wrote:
>
> >
> > Is anybody working on fix ?
> >
>
> Not I, but I can give you some background. The crash seems to only
> occur when the argument of the GROUPed by function is not used elsewhere
> in the target list.

Yes, I see that it comes from replace_agg_clause() after
match_varid() call: for some reasons varoattno of
target list var is changed and so var is not matched...

>
> example:
> select upper(usename), count(usename) from pg_shadow group by 1;
> OK
> select upper(usename), count(oid) from pg_shadow group by 1;
> CRASH
>
> It did work in 6.3.

As I remember, someone re-implemented GroupBy node in 6.4...

Vadim

> >
> > It did work in 6.3.
>
> As I remember, someone re-implemented GroupBy node in 6.4...

I don't think I did.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)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)

David Hartwig wrote:
>
> Vadim Mikheev wrote:
>
> > >
> > > example:
> > > select upper(usename), count(usename) from pg_shadow group by 1;
> > > OK
> > > select upper(usename), count(oid) from pg_shadow group by 1;
> > > CRASH
> > >
> > > It did work in 6.3.
> >
> > As I remember, someone re-implemented GroupBy node in 6.4...
>
> You may be referring to me. I made some changes to the SortGroupBy parse
> node to allow espressions. I didn't touch the GroupClause node. Also,
> I think this bug arrived before I made my changes in 6.4

Ok, I'll take care...

Vadim