Re: TODO items

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

In response to

Responses

Browse pgsql-hackers by date

  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