ParameterStatus message can be sent during COPY OUT: it's definitely
possible, since COPY from a SELECT subquery can trigger any user-defined
function.
>
> * Add the ability to automatically create materialized views
>
> Right now materialized views require the user to create triggers on the
> main table to keep the summary table current. SQL syntax should be able
> to manager the triggers and summary table automatically. A more
> sophisticated implementation would automatically retrieve from the
> summary table when the main table is referenced, if possible.
>
we need to be able to swallow NOTICE messages, and potentially also
ParameterStatus messages (although the latter would be a bit weird),
without exiting COPY OUT state. Fix it, and adjust the protocol documentation
to emphasize the need for this. Per off-list report from Alexander Galler.
and CLUSTER) execute as the table owner rather than the calling user, using
the same privilege-switching mechanism already used for SECURITY DEFINER
functions. The purpose of this change is to ensure that user-defined
functions used in index definitions cannot acquire the privileges of a
superuser account that is performing routine maintenance. While a function
used in an index is supposed to be IMMUTABLE and thus not able to do anything
very interesting, there are several easy ways around that restriction; and
even if we could plug them all, there would remain a risk of reading sensitive
information and broadcasting it through a covert channel such as CPU usage.
To prevent bypassing this security measure, execution of SET SESSION
AUTHORIZATION and SET ROLE is now forbidden within a SECURITY DEFINER context.
Thanks to Itagaki Takahiro for reporting this vulnerability.
Security: CVE-2007-6600
< * Allow major upgrades without dump/reload, perhaps using pg_upgrade
< [pg_upgrade]
< * Check for unreferenced table files created by transactions that were
< in-progress when the server terminated abruptly
<
< http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php
<
> * Check for unreferenced table files created by transactions that were
> in-progress when the server terminated abruptly
>
> http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php
>
< * Support table partitioning that allows a single table to be stored
< in subtables that are partitioned based on the primary key or a WHERE
< clause
< creation of rules for INSERT/UPDATE/DELETE, and constraints for
< rapid partition selection. Options could include range and hash
> creation of triggers or rules for INSERT/UPDATE/DELETE, and constraints
> for rapid partition selection. Options could include range and hash
<
< * Improve replication solutions
<
< o Load balancing
<
< You can use any of the master/slave replication servers to use a
< standby server for data warehousing. To allow read/write queries to
< multiple servers, you need multi-master replication like pgcluster.
<
< o Allow replication over unreliable or non-persistent links
<
<
< o Mark change-on-restart-only values in postgresql.conf
< All objects in the default database tablespace must have default
< tablespace specifications. This is because new databases are
< created by copying directories. If you mix default tablespace
< tables and tablespace-specified tables in the same directory,
< creating a new database from such a mixed directory would create a
< new database with tables that had incorrect explicit tablespaces.
< To fix this would require modifying pg_class in the newly copied
< database, which we don't currently do.
> Currently all objects in the default database tablespace must
> have default tablespace specifications. This is because new
> databases are created by copying directories. If you mix default
> tablespace tables and tablespace-specified tables in the same
> directory, creating a new database from such a mixed directory
> would create a new database with tables that had incorrect
> explicit tablespaces. To fix this would require modifying
> pg_class in the newly copied database, which we don't currently
> do.
<
< o Allow recovery.conf to allow the same syntax as
> o Allow recovery.conf to support the same syntax as
< * Allow user-defined types to specify a type modifier at table creation
< time
< * Allow all data types to cast to and from TEXT
<
< http://archives.postgresql.org/pgsql-hackers/2007-04/msg00017.php
<
<
< o Add support for year-month syntax, INTERVAL '50-6' YEAR TO MONTH
< o Interpret INTERVAL '1 year' MONTH as CAST (INTERVAL '1 year' AS
< INTERVAL MONTH), and this should return '12 months'
> o Add support for year-month syntax, INTERVAL '50-6' YEAR
> TO MONTH
> o Interpret INTERVAL '1 year' MONTH as CAST (INTERVAL '1
> year' AS INTERVAL MONTH), and this should return '12 months'
< * Allow MONEY to be cast to/from other numeric data types
> * Allow MONEY to be easily cast to/from other numeric data types
>
< * Allow functions to have a schema search path specified at creation time
< * Fix cases where invalid byte encodings are accepted by the database,
< but throw an error on SELECT
<
< http://archives.postgresql.org/pgsql-hackers/2007-03/msg00767.php
< * Improve logging of prepared statements recovered during startup
> * Improve logging of prepared transactions recovered during startup
< * Make standard_conforming_strings the default in 8.4?
> * Make standard_conforming_strings the default in 8.5?
< * Allow the count returned by SELECT, etc to be to represent as an int64
> * Allow the count returned by SELECT, etc to be represented as an int64
< o Use more reliable method for CREATE DATABASE to get a consistent
< copy of db?
< o Fix transaction restriction checks for CREATE DATABASE and
< other commands
<
< http://archives.postgresql.org/pgsql-hackers/2007-01/msg00133.php
< currently allowed.
> currently allowed. This currently is done if the table is
> created inside the same transaction block as the COPY because
> no other backends can see the table.
< o Add SET PATH for schemas?
<
< This is basically the same as SET search_path.
< o Enforce referential integrity for system tables
< o Add Oracle-style packages (Pavel)
<
< A package would be a schema with session-local variables,
< public/private functions, and initialization functions. It
< is also possible to implement these capabilities
< in all schemas and not use a separate "packages"
< syntax at all.
<
< http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php
<
< o Add single-step debugging of functions
< o Allow RETURN to return row or record functions
<
< http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php
< http://archives.postgresql.org/pgsql-patches/2006-08/msg00397.php
< http://archives.postgresql.org/pgsql-hackers/2006-09/msg00388.php
<
< o Fix problems with RETURN NEXT on tables with
< dropped/added columns after function creation
<
< http://archives.postgresql.org/pgsql-patches/2006-02/msg00165.php
<
< * Make consistent use of long/short command options --- pg_ctl needs
< long ones, pg_config doesn't have short ones, postgres doesn't have
< enough long ones, etc.
<
<
<
< o Consider parsing the -c string into individual queries so each
< is run in its own transaction
<
< http://archives.postgresql.org/pgsql-hackers/2007-01/msg00291.php
<
<
< o Remove unnecessary function pointer abstractions in pg_dump source
< code
> o Remove unnecessary function pointer abstractions in pg_dump source
> code
<
<
< o Fix SSL retry to avoid useless repeated connection attempts and
< ensuing misleading error messages
>
<
< This is difficult because it requires datatype-specific knowledge.
<
< * Improve commit_delay handling to reduce fsync()
< * %Add an option to sync() before fsync()'ing checkpoint files
>
< * Reduce lock time during VACUUM FULL by moving tuples with read lock,
< then write lock and truncate table
<
< Moved tuples are invisible to other backends so they don't require a
< write lock. However, the read lock promotion to write lock could lead
< to deadlock situations.
<
< * Prevent long-lived temporary tables from causing frozen-xid advancement
< starvation
<
< The problem is that autovacuum cannot vacuum them to set frozen xids;
< only the session that created them can do that.
<
<
<
< o Use free-space map information to guide refilling
< o Consider logging activity either to the logs or a system view
> The problem is that autovacuum cannot vacuum them to set frozen xids;
> only the session that created them can do that.
< * Add connection pooling
<
< It is unclear if this should be done inside the backend code or done
< by something external like pgpool. The passing of file descriptors to
< existing backends is one of the difficulties with a backend approach.
<
< * Consider reducing memory used for shared buffer reference count
<
< http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php
<
< * %Remove memory/file descriptor freeing before ereport(ERROR)
< * %Promote debug_query_string into a server-side function current_query()
< * Allow ecpg to work with MSVC and BCC
< * Add xpath_array() to /contrib/xml2 to return results as an array
< * Allow building in directories containing spaces
<
< This is probably not possible because 'gmake' and other compiler tools
< do not fully support quoting of paths with spaces.
<
< * Fix sgmltools so PDFs can be generated with bookmarks
< * Split out libpq pgpass and environment documentation sections to make
< it easier for non-developers to find
< * Use strlcpy() rather than our StrNCpy() macro
<
< http://archives.postgresql.org/pgsql-hackers/2006-09/msg02108.php
<
< o Re-enable timezone output on log_line_prefix '%t' when a
< shorter timezone string is available
< * Allow statements across databases or servers with transaction
< semantics
<
< This can be done using dblink and two-phase commit.
> * Add Oracle-style packages (Pavel)
< * Add the features of packages
> A package would be a schema with session-local variables,
> public/private functions, and initialization functions. It
> is also possible to implement these capabilities
> in any schema and not use a separate "packages"
> syntax at all.
< o Make private objects accessible only to objects in the same schema
< o Allow current_schema.objname to access current schema objects
< o Add session variables
< o Allow nested schemas
> http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php
< * Experiment with multi-threaded backend better resource utilization
<
< This would allow a single query to make use of multiple CPU's or
< multiple I/O channels simultaneously. One idea is to create a
< background reader that can pre-fetch sequential and index scan
< pages needed by other backends. This could be expanded to allow
< concurrent reads from multiple devices in a partitioned table.
<
> * Experiment with multi-threaded backend better resource utilization
>
> This would allow a single query to make use of multiple CPU's or
> multiple I/O channels simultaneously. One idea is to create a
> background reader that can pre-fetch sequential and index scan
> pages needed by other backends. This could be expanded to allow
> concurrent reads from multiple devices in a partitioned table.
Bruce Momjian