>
> o Allow pg_hba.conf to specify host names along with IP addresses
>
> Host name lookup could occur when the postmaster reads the
> pg_hba.conf file, or when the backend starts. Another
> solution would be to reverse lookup the connection IP and
> check that hostname against the host names in pg_hba.conf.
> We could also then check that the host name maps to the IP
> address.
default"
> or "NO SCROLL is the default", it will be rejected as incorrect. The
> reason is that the default behavior is different from either of these,
> as is explained in the NOTES section.
Ok, so *that's* where the bit about the query plan being simple enough.
Based on that, ISTM that it should be premissable for us to decide that
a cursor requiring a sort isn't "simple enough" to support SCROLL.
In any case, here's a patch that makes the non-standard behavior easier
for people to find.
Jim C. Nasby
comments on cluster global objects like databases, tablespaces, and
roles.
It touches a lot of places, but not much in the way of big changes. The
only design decision I made was to duplicate the query and manipulation
functions rather than to try and have them handle both shared and local
comments. I believe this is simpler for the code and not an issue for
callers because they know what type of object they are dealing with.
This has resulted in a shobj_description function analagous to
obj_description and backend functions [Create/Delete]SharedComments
mirroring the existing [Create/Delete]Comments functions.
pg_shdescription.h goes into src/include/catalog/
Kris Jurka
(optionally) to a new host and port without exiting psql. This
eliminates, IMHO, a surprise in that you can now connect to PostgreSQL
on a differnt machine from the one where you started your session. This
should help people who use psql as an administrative tool.
David Fetter
partial. None of the existing AMs do anything useful except counting
tuples when there's nothing to delete, and we can get a tuple count
from the heap as long as it's not a partial index. (hash actually can
skip anyway because it maintains a tuple count in the index metapage.)
GIST is not currently able to exploit this optimization because, due to
failure to index NULLs, GIST is always effectively partial. Possibly
we should fix that sometime.
Simon Riggs w/ some review by Tom Lane.
< * Allow control over which tables are WAL-logged [walcontrol]
> * Allow WAL logging to be turned off for a table, but the table
> might be dropped or truncated during crash recovery [walcontrol]
< commit. To do this, only a single writer can modify the table, and
< writes must happen only on new pages. Readers can continue accessing
< the table. This would affect COPY, and perhaps INSERT/UPDATE too.
< Another option is to avoid transaction logging entirely and truncate
< or drop the table on crash recovery. These should be implemented
< using ALTER TABLE, e.g. ALTER TABLE PERSISTENCE [ DROP | TRUNCATE |
< STABLE | DEFAULT ]. Tables using non-default logging should not use
< referential integrity with default-logging tables, and tables using
< stable logging probably can not have indexes. One complexity is
< the handling of indexes on TOAST tables.
> commit. This should be implemented using ALTER TABLE, e.g. ALTER
> TABLE PERSISTENCE [ DROP | TRUNCATE | DEFAULT ]. Tables using
> non-default logging should not use referential integrity with
> default-logging tables. A table without dirty buffers during a
> crash could perhaps avoid the drop/truncate.
>
> * Allow WAL logging to be turned off for a table, but the table would
> avoid being truncated/dropped [walcontrol]
>
> To do this, only a single writer can modify the table, and writes
> must happen only on new pages so the new pages can be removed during
> crash recovery. Readers can continue accessing the table. Such
> tables probably cannot have indexes. One complexity is the handling
> of indexes on TOAST tables.
... in fact, it will be applied now in any query whatsoever. I'm still
a bit concerned about the cycles that might be expended in failed proof
attempts, but given that CE is turned off by default, it's the user's
choice whether to expend those cycles or not. (Possibly we should
change the simple bool constraint_exclusion parameter to something
more fine-grained?)
< * Allow control over which tables are WAL-logged
> * Allow control over which tables are WAL-logged [walcontrol]
1038c1038,1039
< stable logging probably can not have indexes. [walcontrol]
> stable logging probably can not have indexes. One complexity is
> the handling of indexes on TOAST tables.
> * Allow statistics collector information to be pulled from the collector
> process directly, rather than requiring the collector to write a
> filesystem file twice a second?
>
> o Prevent tab completion of SET TRANSACTION from querying the
> database and therefore preventing the transaction isolation
> level from being set.
>
> Currently, SET <tab> causes a database lookup to check all
> supported session variables. This query causes problems
> because setting the transaction isolation level must be the
> first statement of a transaction.
< * %Prevent INET cast to CIDR if the unmasked bits are not zero, or
< zero the bits
< * %Prevent INET cast to CIDR from dropping netmask, SELECT '1.1.1.1'::inet::cidr
> * -Zero umasked bits in conversion from INET cast to CIDR
> * -Prevent INET cast to CIDR from dropping netmask, SELECT '1.1.1.1'::inet::cidr
and rely exclusively on the SQL type system to tell the difference between
the types. Prevent creation of invalid CIDR values via casting from INET
or set_masklen() --- both of these operations now silently zero any bits
to the right of the netmask. Remove duplicate CIDR comparison operators,
letting the type rely on the INET operators instead.
suggestion a couple days ago. Fix some cases in which the documentation
neglected to mention any restriction on when a parameter can be set.
Try to be consistent about calling parameters parameters; use the term
option only for command-line switches.
< o Allow an alias to be provided for the target table in
< UPDATE/DELETE
<
< This is not SQL-spec but many DBMSs allow it.
<
> o -Allow an alias to be provided for the target table in
> UPDATE/DELETE (Neil)
and DELETE. If specified, the alias must be used instead of the full
table name. Also, the alias currently cannot be used in the SET clause
of UPDATE.
Patch from Atsushi Ogawa, various editorialization by Neil Conway.
Along the way, make the rowtypes regression test pass if add_missing_from
is enabled, and add a new (skeletal) regression test for DELETE.
be consistent about whether it's called a daemon or a subprocess, and
don't describe the autovacuum setting in exactly the same way as the
stats_start_collector setting, because that leaves people thinking (if
they aren't paying close attention) that autovacuum can't be changed
on the fly.
Continue to support GRANT ON [TABLE] for sequences for backward
compatibility; issue warning for invalid sequence permissions.
[Backward compatibility warning message.]
Add USAGE permission for sequences that allows only currval() and
nextval(), not setval().
Mention object name in grant/revoke warnings because of possible
multi-object operations.
cursors. Patch from Joachim Wieland, review and ediorialization by Neil
Conway. The view lists cursors defined by DECLARE CURSOR, using SPI, or
via the Bind message of the frontend/backend protocol. This means the
view does not list the unnamed portal or the portal created to implement
EXECUTE. Because we do list SPI portals, there might be more rows in
this view than you might expect if you are using SPI implicitly (e.g.
via a procedural language).
Per recent discussion on -hackers, the query string included in the
view for cursors defined by DECLARE CURSOR is based on
debug_query_string. That means it is not accurate if multiple queries
separated by semicolons are submitted as one query string. However,
there doesn't seem a trivial fix for that: debug_query_string
is better than nothing. I also changed SPI_cursor_open() to include
the source text for the portal it creates: AFAICS there is no reason
not to do this.
Update the documentation and regression tests, bump the catversion.
an array of regtype, rather than an array of OIDs. This is likely to
be more useful to user, and the type OID can easily be obtained by
casting a regtype value to OID. Per suggestion from Tom.
Update the documentation and regression tests, and bump the catversion.
data type is unspecified or is declared to be "unknown", the type will
be inferred from the context in which the parameter is used. This was
already possible for protocol-level prepared statements.
permissions on the functions and operators contained in the opclass.
Since we already require superuser privilege to create an operator class,
there's no expansion-of-privilege hazard here, but if someone were to get
the idea of building an opclass containing functions that need security
restrictions, we'd better warn them off. Also, change the permission
checks from have-execute-privilege to have-ownership, and then comment
them all out since they're dead code anyway under the superuser restriction.
type definition. Because use of a type's I/O conversion functions isn't
access-checked, CREATE TYPE amounts to granting public execute permissions
on the functions, and so allowing it to anybody means that someone could
theoretically gain access to a function he's not supposed to be able to
execute. The parameter-type restrictions already enforced by CREATE TYPE
make it fairly unlikely that this oversight is meaningful in practice,
but still it seems like a good idea to plug the hole going forward.
Also, document the implicit grant just in case anybody gets the idea of
building I/O functions that might need security restrictions.
access information about the prepared statements that are available
in the current session. Original patch from Joachim Wieland, various
improvements by Neil Conway.
The "statement" column of the view contains the literal query string
sent by the client, without any rewriting or pretty printing. This
means that prepared statements created via SQL will be prefixed with
"PREPARE ... AS ", whereas those prepared via the FE/BE protocol will
not. That is unfortunate, but discussion on -patches did not yield an
efficient way to improve this, and there is some merit in returning
exactly what the client sent to the backend.
Catalog version bumped, regression tests updated.
< STABLE | DEFAULT ]. [wallog]
> STABLE | DEFAULT ]. Tables using non-default logging should not use
> referential integrity with default-logging tables, and tables using
> stable logging probably can not have indexes. [wallog]
< the table. Another option is to avoid transaction logging entirely
< and truncate or drop the table on crash recovery. These should be
< implemented using ALTER TABLE, e.g. ALTER TABLE PERSISTENCE [ DROP |
< TRUNCATE | STABLE | DEFAULT ]. [wallog]
> the table. This would affect COPY, and perhaps INSERT/UPDATE too.
> Another option is to avoid transaction logging entirely and truncate
> or drop the table on crash recovery. These should be implemented
> using ALTER TABLE, e.g. ALTER TABLE PERSISTENCE [ DROP | TRUNCATE |
> STABLE | DEFAULT ]. [wallog]
>
> * Allow control over which tables are WAL-logged
>
> Allow tables to bypass WAL writes and just fsync() dirty pages on
> commit. To do this, only a single writer can modify the table, and
> writes must happen only on new pages. Readers can continue accessing
> the table. Another option is to avoid transaction logging entirely
> and truncate or drop the table on crash recovery. These should be
> implemented using ALTER TABLE, e.g. ALTER TABLE PERSISTENCE [ DROP |
> TRUNCATE | STABLE | DEFAULT ]. [wallog]
(previously we only did = and <> correctly). Also, allow row comparisons
with any operators that are in btree opclasses, not only those with these
specific names. This gets rid of a whole lot of indefensible assumptions
about the behavior of particular operators based on their names ... though
it's still true that IN and NOT IN expand to "= ANY". The patch adds a
RowCompareExpr expression node type, and makes some changes in the
representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code
with RowCompareExpr.
I have not yet done anything about making RowCompareExpr an indexable
operator, but will look at that soon.
initdb forced due to changes in stored rules.
* %Make row-wise comparisons work per SQL spec
Right now, '(a, b) < (1, 2)' is processed as 'a < 1 and b < 2', but
the SQL standard requires it to be processed as a column-by-column
comparison, so the proper comparison is '(a < 1) OR (a = 1 AND b < 2)'.
Fix example for day and hours interval subtraction for new computation
method.
Update interval examples to display zero seconds, which is our default.
Backpatch to 8.1.X.
Per my recent proposal. I ended up basing the implementation on the
existing mechanism for enforcing valid join orders of IN joins --- the
rules for valid outer-join orders are somewhat similar.
< * Allow star join optimizations
<
< While our bitmap scan allows multiple indexes to be joined to get
< to heap rows, a star joins allows multiple dimension _tables_ to
< be joined to index into a larger main fact table. The join is
< usually performed by either creating a cartesian product of all
< the dimmension tables and doing a single join on that product or
< using subselects to create bitmaps of each dimmension table match
< and merge the bitmaps to perform the join on the fact table. Some
< of these algorithms might be patented.
< * Flush cached query plans when the dependent objects change or
< when the cardinality of parameters changes dramatically
> * Flush cached query plans when the dependent objects change,
> when the cardinality of parameters changes dramatically, or
> when new ANALYZE statistics are available
Drake:
< and merge the bitmaps to perform the join on the fact table.
> and merge the bitmaps to perform the join on the fact table. Some
> of these algorithms might be patented.
* Allow star join optimizations
While our bitmap scan allows multiple indexes to be joined to get
to heap rows, a star joins allows multiple dimension _tables_ to
be joined to index into a larger main fact table. The join is
usually performed by either creating a cartesian product of all
the dimmension tables and doing a single join on that product or
using subselects to create bitmaps of each dimmension table match
and merge the bitmaps to perform the join on the fact table.
< * Flush cached query plans when the dependent objects change
> * Flush cached query plans when the dependent objects change or
> when the cardinality of parameters changes dramatically
< * %Allow pooled connections to list all prepared queries
> * %Allow pooled connections to list all prepared statements
28c28
< the queries prepared in the current session.
> the statements prepared in the current session.
143c143
< o Allow a warm standby system to also allow read-only queries
> o Allow a warm standby system to also allow read-only statements
404c404
< * Add GUC to issue notice about queries that use unjoined tables
> * Add GUC to issue notice about statements that use unjoined tables
490c490
< Another idea would be to allow actual SELECT queries in a COPY.
> Another idea would be to allow actual SELECT statements in a COPY.
554c554
< o Allow function argument names to be queries from PL/PgSQL
> o Allow function argument names to be statements from PL/PgSQL
591c591
< o Improve psql's handling of multi-line queries
> o Improve psql's handling of multi-line statements
< Currently, while \e saves a single query as one entry, interactive
< queries are saved one line at a time. Ideally all queries
> Currently, while \e saves a single statement as one entry, interactive
> statements are saved one line at a time. Ideally all statements
665c665
< o Allow query results to be automatically batched to the client
> o Allow statement results to be automatically batched to the client
667c667
< Currently, all query results are transfered to the libpq
> Currently, all statement results are transfered to the libpq
672c672
< One complexity is that a query like SELECT 1/col could error
> One complexity is that a statement like SELECT 1/col could error
739c739
< * Allow queries across databases or servers with transaction
> * Allow statements across databases or servers with transaction
< inheritance, allow it to work for UPDATE and DELETE queries, and allow
< it to be used for all queries with little performance impact
> inheritance, allow it to work for UPDATE and DELETE statements, and allow
> it to be used for all statements with little performance impact
876c876
< * Consider automatic caching of queries at various levels:
> * Consider automatic caching of statements at various levels:
947c947
< a single session using multiple threads to execute a query faster.
> a single session using multiple threads to execute a statement faster.
1025c1025
< * Log queries where the optimizer row estimates were dramatically
> * Log statements where the optimizer row estimates were dramatically
1146c1146
< of result sets using new query protocol
> of result sets using new statement protocol
DROP CONSTRAINT
This form drops constraints on a table. Currently, constraints on tables
are not required to have unique names, so there may be more than one
constraint matching the specified name. All matching constraints will be
dropped.
To my knowledge, it is no longer possible to create constraints with the
same name for the same relation. When you create a constraint and specify
the same name explictly, an error is raised. Implicit constraint creation
won't choose an existing name either and up to now you could not rename a
constraint. Renaming works with the patch I sent in a few hours ago but this
patch as well won't allow constraints with identical names on the same
relation.
The attached patch thus removes the note in the docs.
Joachim Wieland
the latest release notes there is a latin1 character that shouldn't be
there so I made a patch to fix that. This patch also fixes some old
entries that uses o instead of ö (which is also wrong but not as
bad as including a latin1 character in the sgml file).
Dennis Bj?rklund
< Win32 API, and we have to make sure MinGW handles it.
> Win32 API, and we have to make sure MinGW handles it. Another
> option is to wait for the MinGW project to fix it, or use the
> code from the LibGW32C project as a guide.
> o Add long file support for binary pg_dump output
>
> While Win32 supports 64-bit files, the MinGW API does not,
> meaning we have to build an fseeko replacement on top of the
> Win32 API, and we have to make sure MinGW handles it.
Map them to a single day, so '30 hours' is 'AM'.
Have to_char(interval) and to_char(time) use "HH", "HH12" as 12-hour
intervals, rather than bypass and print the full interval hours. This
is neeeded because to_char(time) is mapped to interval in this function.
Intervals should use "HH24", and document suggestion.
Allow "D" format specifiers for interval/time.
< be cleared when a heap tuple is expired. Another idea is to maintain
< a bitmap of heap pages where all rows are visible to all backends,
< and allow index lookups to reference that bitmap to avoid heap
< lookups, perhaps the same bitmap we might add someday to determine
< which heap pages need vacuuming.
> be cleared when a heap tuple is expired.
>
> Another idea is to maintain a bitmap of heap pages where all rows
> are visible to all backends, and allow index lookups to reference
> that bitmap to avoid heap lookups, perhaps the same bitmap we might
> add someday to determine which heap pages need vacuuming. Frequently
> accessed bitmaps would have to be stored in shared memory. One 8k
> page of bitmaps could track 512MB of heap pages.
< the heap. One way to allow this is to set a bit to index tuples
> the heap. One way to allow this is to set a bit on index tuples
< be cleared when a heap tuple is expired.
<
> be cleared when a heap tuple is expired. Another idea is to maintain
> a bitmap of heap pages where all rows are visible to all backends,
> and allow index lookups to reference that bitmap to avoid heap
> lookups, perhaps the same bitmap we might add someday to determine
> which heap pages need vacuuming.
< * Add MERGE command that does UPDATE/DELETE, or on failure, INSERT (rules,
< triggers?)
> * Add SQL-standard MERGE command, typically used to merge two tables
>
> This is similar to UPDATE, then for unmatched rows, INSERT.
> Whether concurrent access allows modifications which could cause
> row loss is implementation independent.
>
> * Add REPLACE or UPSERT command that does UPDATE, or on failure, INSERT
< #A hyphen, "-", marks changes that will appear in the upcoming 8.1 release.#
> #A hyphen, "-", marks changes that will appear in the upcoming 8.2 release.#
