From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TODO items |
Date: | 2003-08-08 17:09:38 |
Message-ID: | 200308081709.h78H9cO00606@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-08-08 17:12:24 | Re: TODO items |
Previous Message | Tom Lane | 2003-08-08 17:02:25 | Re: consistency check on SPI tuple count failed |