< This would require some background daemon to maintain clustering
> This might require some background daemon to maintain clustering
397,398c397,398
< paritally filled for easier reorganization. It also might require
< creating a merged heap/index data file so an index lookup would
> paritally filled for easier reorganization. Another idea would
> be to create a merged heap/index data file so an index lookup would
< This would require some background daemon to restore clustering
> This would require some background daemon to maintain clustering
397c397,399
< paritally filled for easier reorganization.
> paritally filled for easier reorganization. It also might require
> creating a merged heap/index data file so an index lookup would
> automatically access the heap data too.
> * Merge hardwired timezone names with the TZ database; allow either kind
> everywhere a TZ name is currently taken
> * Allow customization of the known set of TZ names (generalize the
> present australian_timezones hack)
< * Implement dirty reads or shared row locks and use them in RI triggers (?)
> * Implement dirty reads or shared row locks and use them in RI triggers
>
> Adding shared locks requires recording the table/rows numbers in a
> shared area, and this could potentially be a large amount of data.
> One idea is to store the table/row numbers in a separate table and set
> a bit on the row indicating looking in this new table is required to
> find any shared row locks.
>
< o Allow databases, schemas, and indexes to be moved to different
< tablespaces
> o Allow databases and schemas to be moved to different tablespaces
>
> One complexity is whether moving a schema should move all existing
> schema objects or just define the location for future object creation.
>
382c385
< o Add ALTER INDEX that works just like ALTER TABLE already does
> o -Add ALTER INDEX that works just like ALTER TABLE already does
384d386
< o Add ALTER INDEX syntax to work like ALTER TABLE indexname
< * -Have psql \dn show only visible temp schemas using current_schemas()
< * -Have psql '\i ~/<tab><tab>' actually load files it displays from home dir
484a483,484
> * -Have psql \dn show only visible temp schemas using current_schemas()
> * -Have psql '\i ~/<tab><tab>' actually load files it displays from home dir
516a517,527
>
> * psql tab completion
>
> o Provide a list of conversions after ALTER CONVERSION?
> o Support for ALTER SEQUENCE clauses
> o Add RENAME TO to ALTER TRIGGER
> o Support for ALTER USER
> o Fix ALTER (GROUP|DOMAIN|...) <sth> DROP
> o Support for ALTER LANGUAGE <sth> RENAME TO
> o Improve support for COPY
> o Improve support for ALTER TABLE
file variables:
< Another option is to allow commented values to return to their
< default values.
> This has to address environment variables that are then overridden
> by config file values. Another option is to allow commented values
> to return to their default values.
< * -Allow pg_dump to dump CREATE CONVERSION (Christopher)
< * -Make pg_restore continue after errors, so it acts more like pg_dump scripts
485,486d482
< * Allow pg_dumpall to use non-text output formats
< * Have pg_dump use multi-statement transactions for INSERT dumps
493,496d488
< * Allow pg_dump to use multiple -t and -n switches
<
< This should be done by allowing a '-t schema.table' syntax.
<
498a491,512
>
> * pg_dump
> o Allow pg_dumpall to use non-text output formats
> o Have pg_dump use multi-statement transactions for INSERT dumps
> o -Allow pg_dump to dump CREATE CONVERSION (Christopher)
> o -Make pg_restore continue after errors, so it acts more like pg_dump
> scripts
> o Allow pg_dump to use multiple -t and -n switches
>
> This should be done by allowing a '-t schema.table' syntax.
>
> o Add dumping of comments on composite type columns
> o Add dumping of comments on index columns
> o Replace crude DELETE FROM method of pg_dumpall for cleaning of
> users and groups with separate DROP commands
> o Add dumping and restoring of LOB comments
> o Stop dumping CASCADE on DROP TYPE commands in clean mode
> o Add full object name to the tag field. eg. for operators we need
> '=(integer, integer)', instead of just '='.
> o Add pg_dumpall custom format dumps. This is probably best done by
> combining pg_dump and pg_dumpall into a single binary
> o Add CSV output format
< * -Allow savepoints / nested transactions [transactions] (Alvaro)
> * -Allow savepoints / nested transactions (Alvaro)
348a349,353
> * Add an option to automatically use savepoints for each statement in a
> multi-statement transaction.
>
> When enabled, this would allow errors in multi-statement transactions
> to be automatically ignored.
> * Set proper permissions on non-system schemas during db creation
>
> Currently all schemas are owned by the super-user because they are
> copied from the template1 database.
>
>
> * Allow buffered WAL writes and fsync
>
> Instead of guaranteeing recovery of all committed transactions, this
> would provide improved performance by delaying WAL writes and fsync
> so an abrupt operating system restart might lose a few seconds of
> committed transactions but still be consistent. We could perhaps
> remove the 'fsync' parameter (which results in an an inconsistent
> database) in favor of this capability.
> * Allow finer control over the caching of prepared query plans
>
> Currently, queries prepared via the libpq API are planned on first
> execute using the supplied parameters --- allow SQL PREPARE to do the
> same. Also, allow control over replanning prepared queries either
> manually or automatically when statistics for execute parameters
> differ dramatically from those used during planning.
>
< * Allow DELETE to handle table aliases for self-joins
> * Allow an alias to be provided for the target table in UPDATE/DELETE
276,279c276,282
< There is no way to create a table alias for the deleted table for use
< in the DELETE WHERE clause. The agreed approach is to allow a USING
< clause to specify additional tables. UPDATE already has an optional
< FROM clause for this purpose.
> This is not SQL-spec but many DBMSs allow it.
>
> * Allow additional tables to be specified in DELETE for joins
>
> UPDATE already allows this (UPDATE...FROM) but we need similar
> functionality in DELETE. It's been agreed that the keyword should
> be USING, to avoid anything as confusing as DELETE FROM a FROM b.
> * Un-comment all variables in postgresql.conf
84,85c84,85
< By removing comments we prevent the confusion that commenting a line
< returns a modified value to its default, which it does not.
> By not showing commented-out variables, we discourage people from
> thinking that re-commenting a variable returns it to its default.
< o -Allow parameters to be specified by name and type during definition
> o -Allow PL/pgSQL parameters to be specified by name and type during definition
Bruce Momjian
Tom Lane