use RESET CONNECTION:
< * Add RESET SESSION command to reset all session state
> * Add RESET CONNECTION command to reset all session state
447c447
< notify the protocol when a RESET SESSION command is used.
> notify the protocol when a RESET CONNECTION command is used.
< * Add RESET CONNECTION command to reset all session state
> * Add RESET SESSION command to reset all session state
447c447
< notify the protocol when a RESET CONNECTION command is used.
> notify the protocol when a RESET SESSION command is used.
< o %Prevent child tables from altering or dropping constraints
< like CHECK that were inherited from the parent table
< like CHECK that are inherited by child tables
<
< Dropping constraints should only be possible with CASCADE.
<
> like CHECK that are inherited by child tables unless CASCADE
> is used
> o %Prevent child tables from altering or dropping constraints
> like CHECK that were inherited from the parent table
o Support ISO INTERVAL syntax if units cannot be determined from
the string, and are supplied after the string
The SQL standard states that the units after the string specify
the units of the string, e.g. INTERVAL '2' MINUTE should
return '00:02:00'. The current behavior has the units
restrict the interval value to the specified unit or unit range,
INTERVAL '70' SECOND returns '00:00:10'.
For syntax that isn't uniquely ISO or PG syntax, like '1' or
'1:30', treat as ISO if there is a range specification clause,
and as PG if there no clause is present, e.g. interpret
'1:30' MINUTE TO SECOND as '1 minute 30 seconds', and
interpret '1:30' as '1 hour, 30 minutes'.
This makes common cases like SELECT INTERVAL '1' MONTH
SQL-standard results. The SQL standard supports a limited
number of unit combinations and doesn't support unit names
in the string. The PostgreSQL syntax is more flexible in
the range of units supported, e.g. PostgreSQL supports
'1 year 1 hour', while the SQL standard does not.
< * -Eventually enable escape_string_warning and standard_conforming_strings
> * -Enable escape_string_warning and standard_conforming_strings
> * Make standard_conforming_strings the default in 8.3?
>
> When this is done, backslash-quote should be prohibited in non-E''
> strings because of possible confusion over how such strings treat
> backslashes. Basically, '' is always safe for a literal single
> quote, while \' might or might not be based on the backslash
> handling rules.
>
permission item:
< o %Allow pg_hba.conf settings to be controlled via SQL
> o %Allow per-database permissions to be set via GRANT
< This would add a function to load the SQL table from
< pg_hba.conf, and one to writes its contents to the flat file.
< The table should have a line number that is a float so rows
< can be inserted between existing rows, e.g. row 2.5 goes
< between row 2 and row 3.
> Allow database connection checks based on GRANT rules in
> addition to the existing access checks in pg_hba.conf.
>
> o Add new version of PQescapeString() that doesn't double backslashes
> that are part of a client-only multibyte sequence
>
> Single-quote is not a valid byte in any supported client-only
> encoding.
>
> o Add new version of PQescapeString() that doesn't double
> backslashes when standard_conforming_strings is true and
> non-E strings are used
< multiple I/O channels simultaneously.
> 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.
<P>The maximum table size, row size, and maximum number of columns
can be quadrupled by increasing the default block size to 32k. The
maximum table size can also be increased using table partitioning.</P>
> * Allow log_min_messages to be specified on a per-module basis
>
> This would allow administrators to see more detailed information from
> specific sections of the backend, e.g. checkpoints, autovacuum, etc.
< * Experiment with multi-threaded backend [thread]
> * Experiment with multi-threaded backend for backend creation [thread]
1003a1004,1008
>
> * 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.
> * Allow the creation of indexes with mixed ascending/descending
> specifiers
>
> This is possible now by creating an operator class with reversed sort
> operators. One complexity is that NULLs would then appear at the start
> of the result set, and this might affect certain sort types, like
> merge join.
>
> o Prevent parent tables from altering or dropping constraints
> like CHECK that are inherited by child tables
>
> Dropping constraints should only be possible with CASCADE.
>
< * %Disallow changing sequence characteristics like INCREMENT for SERIAL columns
> * %Disallow ALTER SEQUENCE changes for SERIAL sequences because pg_dump
> does not dump the changes
