TODO list comments - Mailing list pgsql-hackers

I made a pass over the TODO list to see what was out of date.

> * Allow administrators to safely terminate individual sessions either
>   via an SQL function or SIGTERM 
> 
>   Currently SIGTERM of a backend can lead to lock table corruption.

This comment may be out of date.  Suggest
Lock table corruption following SIGTERM of an individual backendhas been reported in 8.0.  A possible cause is fixed in
8.1,butit is unknown whether other trouble spots exist.  This item ismainly a matter of doing adequate testing rather
thanof writingany new code.
 

>     o Allow postgresql.conf values to be set so they can not be changed
>       by the user

Is that really a good idea?  The ones that are unsafe are restricted already.

> * %Remove Money type, add money formatting for decimal type

There's a fair-size contingent that doesn't want Money removed
completely, but just reimplemented as an I/O wrapper around type
numeric.  Maybe that's even what you mean by the TODO item, but
it's not clear.  Please at least mention the alternative.

>     o %Allow MIN()/MAX() on arrays

This is done.

>     o Modify array literal representation to handle array index lower bound
>       of other than one

This too.

>     o Add security checking for large objects
> 
>       Currently large objects entries do not have owners. Permissions can
>       only be set at the pg_largeobject table level.

This comment is wrong: trying to set the permissions on pg_largeobject
would have no effect whatsoever on the lo_xxx functions, so there is not
even a partial solution available now.

>     o Auto-delete large objects when referencing row is deleted

This should note that contrib/lo already offers a solution.

> * %Have views on temporary tables exist in the temporary namespace
> * Allow temporary views on non-temporary tables

Both of these are done in 8.1.

> * %Allow RULE recompilation

Eh?  Perhaps you meant "automatically regenerate cached plans when
needed", in which case it's redundant with the Dependency Checking
entries.  Whatever it means, this doesn't seem a particularly simple
item.

> * %Allow TRUNCATE ... CASCADE/RESTRICT

Huh?  What would that do?

> * Make row-wise comparisons work per SQL spec

This could probably be marked as a % item.

>     o Currently the system uses the operating system COPY command to
>       create a new database. Add ON COMMIT capability to CREATE TABLE AS
>       SELECT

This seems a bit garbled, and anyway the first part is done.

>     o %Add ALTER DOMAIN TYPE

To do what, exactly?  This is unclear.

>     o -Allow objects to be moved to different schemas

This is only partly done --- the 8.1 patch didn't cover all object types.

>     o %Disallow dropping of an inherited constraint
> ...
>     o %Prevent child tables from altering constraints like CHECK that were
>       inherited from the parent table

These seem to be duplicates, or at least in need of merging.

>     o Handle references to temporary tables that are created, destroyed,
>       then recreated during a session, and EXECUTE is not used
> 
>       This requires the cached PL/PgSQL byte code to be invalidated when
>       an object referenced in the function is changed.

This is redundant with the Dependency Checking item about regenerating
cached plans.

>     o Add table function support to pltcl, plperl, plpython?

Isn't this done for plperl?

>     o Allow PL/pgSQL to name columns by ordinal position, e.g. rec.(3)

This doesn't seem like an amazingly good idea; would prefer to see a way
to get the column name list and use names dynamically.  Numbers have all
the same problems as "SELECT *" ...

>     o Add MOVE to PL/pgSQL

This should be generalized: upgrade plpgsql cursor support to have all
the FETCH and MOVE options of the main language.

>     o Add support for polymorphic arguments and return types to plperl

I think all the PLs except plpgsql need this.

Also, all the PLs except plpgsql are well behind the curve on supporting
parameter names and OUT parameters.  Please add TODO item(s) for these.

> * Allow libpq to access SQLSTATE so pg_ctl can test for connection failure
> 
>   This would be used for checking if the server is up.

Huh?  What has SQLSTATE got to do with connection failure checking?

> * Have initdb set DateStyle based on locale?

Is this really a good idea?  Being standardized on ISO format seems like
a good thing to me, and encouraging people to adopt ambiguous formats as
default a very bad thing.  They can do it if they like, certainly, but
having initdb do it for them just seems like not the direction we want.

> * Add a schema option to createlang

This is superseded by events: createlang now puts the functions in
pg_catalog, and there doesn't seem any particularly good reason to
want to put them elsewhere.

>     o Improve psql's handling of multi-line queries

Uh, what's wrong with it?  This item seems far too vague.

>     o Add pg_dumpall custom format dumps.
> 
>       This is probably best done by combining pg_dump and pg_dumpall
>       into a single binary.

This is probably obsoleted by events, too.  Now that we can dump blobs
in text mode, I see no reason that we ever need to do this.
pg_restore's only real reason to live is to support selective restore
(ie, pulling out just a few objects from an existing dump) and I do not
see that you need that for pg_dumpall dumps.

>     o Remove unnecessary abstractions in pg_dump source code

Like which?

> * %Remove CREATE CONSTRAINT TRIGGER
> 
>   This was used in older releases to dump referential integrity
>   constraints.

Do we really want to remove it, and thereby guarantee we can't load
dumps from those old releases?

> * Fetch heap pages matching index entries in sequential order
> 
>   Rather than randomly accessing heap pages based on index entries, mark
>   heap pages needing access in a bitmap and do the lookups in sequential
>   order. Another method would be to sort heap ctids matching the index
>   before accessing the heap rows.

This is done (see bitmap index scans).

> * Hash

Why doesn't the hash index section mention the need for WAL support?
Multicolumn hash indexes might be interesting too.

>     o Pack hash index buckets onto disk pages more efficiently
> 
>       Currently no only one hash bucket can be stored on a page. Ideally
>       several hash buckets could be stored on a single page and greater
>       granularity used for the hash algorithm.

I think that should read "Currently only one ..."

> * Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options

This item should probably point out that the optimal settings are
certainly platform-dependent.

> * Improve the background writer
> 
>   Allow the background writer to more efficiently write dirty buffers
>   from the end of the LRU cache and use a clock sweep algorithm to
>   write other dirty buffers to reduced checkpoint I/O

This is done.

> * Improve speed with indexes
> 
>   For large table adjustements during vacuum, it is faster to reindex
>   rather than update the index.

This applies only to VACUUM FULL, so it probably needs to be reworded.

> * Reduce lock time by moving tuples with read lock, then write
>   lock and truncate table

Ditto.

> * Auto-vacuum
> 
>     o %Suggest VACUUM FULL if a table is nearly empty

It seems like a fairly bad idea for auto-vacuum to do a VACUUM FULL
ever, given the locking effects.  And how is a background daemon going
to "suggest" anything?  It could write to the postmaster log but it's
entirely likely the user would never notice.

> * -Improve SMP performance on i386 machines
> 
>   i386-based SMP machines can generate excessive context switching
>   caused by lock failure in high concurrency situations. This may be
>   caused by CPU cache line invalidation inefficiencies.

This isn't really done, I don't think, we just ameliorated what was the
largest cause of it.  It'll be back...

> * Fix priority ordering of read and write light-weight locks (Neil)

I think we concluded that was a bad idea.

> * Add WAL index reliability improvement to non-btree indexes

Oh, here it is.  I'd be inclined to put this item in the index section
instead, so that you can have separate entries for each index type.
Besides, GIST is done.

> * -Use CHECK constraints to influence optimizer decisions
> 
>   CHECK constraints contain information about the distribution of values
>   within the table. This is also useful for implementing subtables where
>   a tables content is distributed across several subtables.

This isn't completely done by any means.

> * ANALYZE should record a pg_statistic entry for an all-NULL column

This is done.

> * Remove memory/file descriptor freeing before ereport(ERROR)
> * Promote debug_query_string into a server-side function current_query()
> * Allow the identifier length to be increased via a configure option

All of those could probably be marked %.

> * Allow cross-compiling by generating the zic database on the target system
> * Fix cross-compiling of time zone database via 'zic'

These look like duplicates to me ...

>     o Improve dlerror() reporting string

I think this got done.

>         o Add support for Unicode

This is done too, though not tested enough.
        regards, tom lane