>
> * Set client encoding based on the client operating system encoding
>
> Currently client_encoding is set in postgresql.conf, which
> defaults to the server encoding.
< o Reorder physical storage order to reduce padding?
<
< This involves having the user-specified order of columns
< be different from the physical order. SELECT * would
< need to reorder the physical values to match the
< user-specified ordering.
<
< o Store disk pages with no alignment/padding?
<
< This necessitates adding CPU-required padding when moving
< rows from disk to memory.
<
< One idea is to store the header in network byte order (high bits
< first), and read the high bits to determine the header length.
< http://archives.postgresql.org/pgsql-hackers/2006-09/msg00848.php
> One idea is to create zero-or-one-byte-header versions
> of varlena data types. In involves setting the high-bit and
> 0-127 length in the single-byte header, or clear the high bit
> and store the 7-bit ASCII value in the rest of the byte.
> The small-header versions have no alignment requirements.
> http://archives.postgresql.org/pgsql-hackers/2006-09/msg01372.php
< o Store disk pages with no alignment/padding?
>
> This involves having the user-specified order of columns
> be different from the physical order. SELECT * would
> need to reorder the physical values to match the
> user-specified ordering.
>
> o Store disk pages with no alignment/padding?
>
> This necessitates adding CPU-required padding when moving
> rows from disk to memory.
>
>
> http://archives.postgresql.org/pgsql-hackers/2006-09/msg00848.php
>
< * Research storing disk pages with no alignment/padding
> * Consider ways of storing rows more compactly on disk
>
> o Store disk pages with no alignment/padding?
> o Reorder physical storage order to reduce padding?
> o Support a smaller header for short variable-length fields?
> o Reduce the row header size?
> * Simplify ability to create partitioned tables
>
> This would allow creation of partitioned tables without requiring
> creation of rules for INSERT/UPDATE/DELETE, and constraints for
> rapid partition selection. Options could include range and hash
> partition selection.
>
> * Allow auto-selection of partitioned tables for min/max() operations
< Last updated: Sat Sep 2 08:31:04 EDT 2006
> Last updated: Sat Sep 2 16:31:46 EDT 2006
< o Allow UPDATE tab SET ROW (col, ...) = (...) for updating multiple
< columns
> o -Allow UPDATE tab SET ROW (col, ...) = (val, ...) for updating
> multiple columns
> o Allow UPDATE tab SET ROW (col, ...) = (SELECT...)
< A subselect can also be used as the value source.
< Last updated: Tue Aug 29 12:21:52 EDT 2006
> Last updated: Wed Aug 30 20:34:28 EDT 2006
< o Allow COPY (SELECT ...) TO 'filename'
<
< COPY should also be able to output views using COPY (SELECT
< * FROM view) TO 'filename' internally.
< http://archives.postgresql.org/pgsql-patches/2005-09/msg00148.php
> o -Allow COPY (SELECT ...) TO 'filename'
> o Allow DEFERRABLE and end-of-statement UNIQUE constraints?
>
> This would allow UPDATE tab SET col = col + 1 to work if col has
> a unique index. Currently, uniqueness checks are done while the
> command is being executed, rather than at the end of the statement
> or transaction.
>
<
< * Allow DEFERRABLE and end-of-statement UNIQUE constraints?
<
< This would allow UPDATE tab SET col = col + 1 to work if col has
< a unique index. Currently, uniqueness checks are done while the
< command is being executed, rather than at the end of the statement
< or transaction.
< * Allow DEFERRABLE UNIQUE constraints?
> * Allow DEFERRABLE and end-of-statement UNIQUE constraints?
>
> This would allow UPDATE tab SET col = col + 1 to work if col has
> a unique index. Currently, uniqueness checks are done while the
> command is being executed, rather than at the end of the statement
> or transaction.
>
< * All backends running as threads in a single process (not want)
> * All backends running as threads in a single process (not wanted)
< * Optimizer hints (not want)
> * Optimizer hints (not wanted)
>
> * Allow AS in "SELECT col AS label" to be optional (not wanted)
>
> Because we support postfix operators, it isn't possible to make AS
> optional and continue to use bison.
> http://archives.postgresql.org/pgsql-sql/2006-08/msg00164.php
< o Allow COPY to output from SELECT
> o Allow COPY (SELECT ...) TO 'filename'
< COPY should also be able to output views.
> COPY should also be able to output views using COPY (SELECT
> * FROM view) TO 'filename' internally.
< * %Disallow changing DEFAULT expression of a SERIAL column?
<
< This should be done only if the existing SERIAL problems cannot be
< fixed.
<
< * %Disallow ALTER SEQUENCE changes for SERIAL sequences because pg_dump
< does not dump the changes
< o Allow INSERT/UPDATE ... RETURNING new.col or old.col
<
< This is useful for returning the auto-generated key for an INSERT.
< One complication is how to handle rules that run as part of
< the insert.
< http://archives.postgresql.org/pgsql-patches/2005-07/msg00568.php
> o -Allow INSERT/UPDATE ... RETURNING new.col or old.col
>
>
> Features We Do _Not_ Want
> =========================
>
> * All backends running as threads in a single process (not want)
>
> This eliminates the process protection we get from the current setup.
> Thread creation is usually the same overhead as process creation on
> modern systems, so it seems unwise to use a pure threaded model.
>
> * Optimizer hints (not want)
>
> Optimizer hints are used to work around problems in the optimizer. We
> would rather have the problems reported and fixed.
> http://archives.postgresql.org/pgsql-hackers/2006-08/msg00506.php
< A package would be a schema with its own variables,
< private functions, and initialization functions. It
> A package would be a schema with public/private variables,
> public/private functions, and initialization functions. It
< private functions, and initialization functions
> 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.
Bruce Momjian