Re: TODO items - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: TODO items |
Date | |
Msg-id | 200308081709.h78H9cO00606@candle.pha.pa.us Whole thread Raw |
In response to | Re: TODO items (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I am marking the completed TODO items. Are these done? > > > * Have standalone backend read postgresql.conf > > [looks] Nope. No ProcessConfigFile() call in postgres.c. OK. > > > * Prevent whole-row references from leaking memory, e.g. SELECT > > COUNT(tab.*) > > Nope. OK, I wasn't sure because you had done per-tuple memory contexts. > > * Use index to restrict rows returned by multi-key index when used with > > non-consecutive keys or OR clauses, so fewer heap accesses > > Not sure what this means. This is a Vadim idea. The idea was that if you had a multi-key index on col1,col2,col3, and you wanted to do a lookup on col1,col3, you could still use the index, and just run through all the matching col1 values looking for a matching col3 in the index, rather than going to the heap and looking for a col3 match? Is this item worth keeping? > > > * Prevent index uniqueness checks when UPDATE does not modify the column > > Not done. OK. > > * Return proper effected tuple count from complex commands [return] > > I looked at that TODO.detail file, and it all seems to be ancient > history. Didn't we resolve those issues to peoples' satisfaction in 7.3? I think so. I think MOVE was our last one. > > o Allow SHOW of non-modifiable variables, like pg_controldata > > I put in read-only variables for the things that seemed most interesting > (LC_COLLATE for example), but the coverage isn't complete. I modified the item to say "some" and marked it as done: o -Allow SHOW of some non-modifiable variables, like pg_controldata Anyone want it kept? > > o Allow array declarations and other data types in PL/PgSQL DECLARE > > AFAIK this is pretty much fixed. OK. Already reported by Joe. > > > o Add PL/PgSQL PROCEDURES that can return multiple values > > Not done (unless this is referring to RETURN NEXT, but I think it's > talking about multiple output parameters). I am asking Josh for a new item with clearer wording. Once we finish some items, the wording often needs adjusting. > > o Add table function support to pltcl, plperl, plpython > > Not done. OK. > > o Allow PL/PgSQL to support array element assignment > > Done. OK. > > * Make blind writes go through the file descriptor cache > > Not done. OK. > > > * Improve Subplan list handling > > Dunno what this is referring to. I assume it is related to the subquery stuff you did. I have marked it as done. > > * Precompile SQL functions to avoid overhead (Neil) > > Not done. OK. > > * Add optional CRC checksum to heap and index pages > > Not done. OK. > > o Add optional textual message to NOTIFY > > Not done, but there is room in the FE/BE protocol now for something like > this. OK. Thanks. TODO updated. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
pgsql-hackers by date: