Correctifs appliqués

Simon Riggs a poussé :

Alvaro Herrera a poussé :

Bruce Momjian a poussé :

Robert Haas a poussé :

Tom Lane a poussé :

  • Tweak new Perl pgindent for compatibility with middle-aged Perls. We seem to have a rough policy that our Perl scripts should work with Perl 5.8, so make this one do so. Main change is to not use the newfangled \h character class in regexes; "[ \t]" is a serviceable replacement. http://git.postgresql.org/pg/commitdiff/5078be480412790e4f1b2aeda04f8c65fc7a3b93
  • Implement SQL-standard LATERAL subqueries. This patch implements the standard syntax of LATERAL attached to a sub-SELECT in FROM, and also allows LATERAL attached to a function in FROM, since set-returning function calls are expected to be one of the principal use-cases. The main change here is a rewrite of the mechanism for keeping track of which relations are visible for column references while the FROM clause is being scanned. The parser "namespace" lists are no longer lists of bare RTEs, but are lists of ParseNamespaceItem structs, which carry an RTE pointer as well as some visibility-controlling flags. Aside from supporting LATERAL correctly, this lets us get rid of the ancient hacks that required rechecking subqueries and JOIN/ON and function-in-FROM expressions for invalid references after they were initially parsed. Invalid column references are now always correctly detected on sight. In passing, remove assorted parser error checks that are now dead code by virtue of our having gotten rid of add_missing_from, as well as some comments that are obsolete for the same reason. (It was mainly add_missing_from that caused so much fudging here in the first place.) The planner support for this feature is very minimal, and will be improved in future patches. It works well enough for testing purposes, though. catversion bump forced due to new field in RangeTblEntry. http://git.postgresql.org/pg/commitdiff/5ebaaa49445eb1ba7b299bbea3a477d4e4c0430b
  • Fix TwoPhaseGetDummyBackendId(). This was broken in commit ed0b409d22346b1b027a4c2099ca66984d94b6dd, which revised the GlobalTransactionData struct to not include the associated PGPROC as its first member, but overlooked one place where a cast was used in reliance on that equivalence. The most effective way of fixing this seems to be to create a new function that looks up the GlobalTransactionData struct given the XID, and make both TwoPhaseGetDummyBackendId and TwoPhaseGetDummyProc rely on that. Per report from Robert Ross. http://git.postgresql.org/pg/commitdiff/db108349bf7fe7fe82e2ff32e42436cfbc4f37dc
  • Update isolation tests' README file. The directions explaining about running the prepared-transactions test were not updated in commit ae55d9fbe3871a5e6309d9b91629f1b0ff2b8cba. http://git.postgresql.org/pg/commitdiff/633f2fbd8835b5a46959e2fda88003f45f7fdba0
  • Merge parser's p_relnamespace and p_varnamespace lists into a single list. Now that we are storing structs in these lists, the distinction between the two lists can be represented with a couple of extra flags while using only a single list. This simplifies the code and should save a little bit of palloc traffic, since the majority of RTEs are represented in both lists anyway. http://git.postgresql.org/pg/commitdiff/f630157496a70f8ece4fd4c27eeead88c74b9015
  • Centralize the logic for detecting misplaced aggregates, window funcs, etc. Formerly we relied on checking after-the-fact to see if an expression contained aggregates, window functions, or sub-selects when it shouldn't. This is grotty, easily forgotten (indeed, we had forgotten to teach DefineIndex about rejecting window functions), and none too efficient since it requires extra traversals of the parse tree. To improve matters, define an enum type that classifies all SQL sub-expressions, store it in ParseState to show what kind of expression we are currently parsing, and make transformAggregateCall, transformWindowFuncCall, and transformSubLink check the expression type and throw error if the type indicates the construct is disallowed. This allows removal of a large number of ad-hoc checks scattered around the code base. The enum type is sufficiently fine-grained that we can still produce error messages of at least the same specificity as before. Bringing these error checks together revealed that we'd been none too consistent about phrasing of the error messages, so standardize the wording a bit. Also, rewrite checking of aggregate arguments so that it requires only one traversal of the arguments, rather than up to three as before. In passing, clean up some more comments left over from add_missing_from support, and annotate some tests that I think are dead code now that that's gone. (I didn't risk actually removing said dead code, though.) http://git.postgresql.org/pg/commitdiff/eaccfded98a9c677d3a2e849c1747ec90e8596a6
  • Update overlooked comment. http://git.postgresql.org/pg/commitdiff/a67d6d9a78fc7ae84e37b8984f2ecbb40a587400
  • Support having multiple Unix-domain sockets per postmaster. Replace unix_socket_directory with unix_socket_directories, which is a list of socket directories, and adjust postmaster's code to allow zero or more Unix-domain sockets to be created. This is mostly a straightforward change, but since the Unix sockets ought to be created after the TCP/IP sockets for safety reasons (better chance of detecting a port number conflict), AddToDataDirLockFile needs to be fixed to support out-of-order updates of data directory lockfile lines. That's a change that had been foreseen to be necessary someday anyway. Honza Horak, reviewed and revised by Tom Lane http://git.postgresql.org/pg/commitdiff/c9b0cbe98bd783e24a8c4d8d8ac472a494b81292
  • Fix dependencies generated during ALTER TABLE ADD CONSTRAINT USING INDEX. This command generated new pg_depend entries linking the index to the constraint and the constraint to the table, which match the entries made when a unique or primary key constraint is built de novo. However, it did not bother to get rid of the entries linking the index directly to the table. We had considered the issue when the ADD CONSTRAINT USING INDEX patch was written, and concluded that we didn't need to get rid of the extra entries. But this is wrong: ALTER COLUMN TYPE wasn't expecting such redundant dependencies to exist, as reported by Hubert Depesz Lubaczewski. On reflection it seems rather likely to break other things as well, since there are many bits of code that crawl pg_depend for one purpose or another, and most of them are pretty naive about what relationships they're expecting to find. Fortunately it's not that hard to get rid of the extra dependency entries, so let's do that. Back-patch to 9.1, where ALTER TABLE ADD CONSTRAINT USING INDEX was added. http://git.postgresql.org/pg/commitdiff/b53800355f9b3a4a4ee6e5e610accab77af8d1c3
  • Add link from COPY ref page to psql \copy. Jeff Janes http://git.postgresql.org/pg/commitdiff/83af58f6b5657840f5924332fccecca1e3556abe
  • Fix some issues with LATERAL(SELECT UNION ALL SELECT). The LATERAL marking has to be propagated down to the UNION leaf queries when we pull them up. Also, fix the formerly stubbed-off set_append_rel_pathlist(). It does already have enough smarts to cope with making a parameterized Append path at need; it just has to not assume that there *must* be an unparameterized path. http://git.postgresql.org/pg/commitdiff/e76af54137c051cafcb1e39f68383a31d1d55ff6
  • More fixes for planner's handling of LATERAL. Re-allow subquery pullup for LATERAL subqueries, except when the subquery is below an outer join and contains lateral references to relations outside that outer join. If we pull up in such a case, we risk introducing lateral cross-references into outer joins' ON quals, which is something the code is entirely unprepared to cope with right now; and I'm not sure it'll ever be worth coping with. Support lateral refs in VALUES (this seems to be the only additional path type that needs such support as a consequence of re-allowing subquery pullup). Put in a slightly hacky fix for joinpath.c's refusal to consider parameterized join paths even when there cannot be any unparameterized ones. This was causing "could not devise a query plan for the given query" failures in queries involving more than two FROM items. Put in an even more hacky fix for distribute_qual_to_rels() being unhappy with join quals that contain references to rels outside their syntactic scope; which is to say, disable that test altogether. Need to think about how to preserve some sort of debugging cross-check here, while not expending more cycles than befits a debugging cross-check. http://git.postgresql.org/pg/commitdiff/c1774d2c8193a322706f681dd984ac439d3a9dbb

Magnus Hagander a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Pavel Stehule sent in a patch to allow pretty-printing queries.
  • Alexander Korotkov sent in another revision of the patch to make SP-GiST for ranges more efficient using 2-d mapping and quad-tree.
  • Pavel Stehule sent in another revision of the patch to allow assigning a single-row query's target list to a corresponding list of psql variables using a new command \gset.
  • Fujii Masao sent in a patch to fix a bug in pg_trgm.
  • Jeff Davis sent in another revision of the patch to add 16-bit checksums to data pages.
  • Alexander Korotkov sent in two more revisions of a patch to improve statistics and selectivity estimation for ranges.
  • Craig Ringer sent in a patch to implement value_to_json for single-datum conversion.