aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Fix description of pg_class.relam for table access methodsMichael Paquier2019-06-20
| | | | | Author: Ian Barwick Discussion: https://postgr.es/m/087a6961-1aaf-e36c-b712-bd5a644da20a@2ndquadrant.com
* pg_upgrade: Improve error messagesPeter Eisentraut2019-06-19
| | | | | | Make wording more accurate and add strerror() information. Discussion: https://www.postgresql.org/message-id/24c8bd05-aed1-6301-919d-8acbabdb8c24@2ndquadrant.com
* pg_upgrade: Improve invalid option handlingPeter Eisentraut2019-06-19
| | | | | | | | | Currently, calling pg_upgrade with an invalid command-line option aborts pg_upgrade but leaves a pg_upgrade_internal.log file lying around. Reorder things a bit so that that file is not created until all the options have been parsed. Discussion: https://www.postgresql.org/message-id/24c8bd05-aed1-6301-919d-8acbabdb8c24@2ndquadrant.com
* Fix description for $varname jsonpath variableAlexander Korotkov2019-06-19
| | | | | | | | | | The description is ended part way and PASSING clause is not implemented yet. But the variables might be passed as parameters to several jsonpath functions. So, complete the description based on the current implementation, leaving description of PASSING clause in TODO. Discussion: https://postgr.es/m/CAKPRHz%2BxOuQSSvkuB1mCQjedd%2BB2B1Vnkrq0E-pLmoXyTO%2Bz9Q%40mail.gmail.com Author: Kyotaro Horiguchi, Alexander Korotkov
* Improve documentation for jsonpath like_regex predicateAlexander Korotkov2019-06-19
| | | | | | | Reference posix regex documentation section and list supported flags. Discussion: https://postgr.es/m/CAKPRHz%2BxOuQSSvkuB1mCQjedd%2BB2B1Vnkrq0E-pLmoXyTO%2Bz9Q%40mail.gmail.com Author: Kyotaro Horiguchi, Alexander Korotkov
* Support 'q' flag in jsonpath 'like_regex' predicateAlexander Korotkov2019-06-19
| | | | | | | | | SQL/JSON standard defines that jsonpath 'like_regex' predicate should support the same set of flags as XQuery/XPath. It appears that implementation of 'q' flag was missed. This commit fixes that. Discussion: https://postgr.es/m/CAPpHfdtyfPsxLYiTjp5Ov8T5xGsB5t3CwE5%2B3PS%3DLLwA%2BxTJog%40mail.gmail.com Author: Nikita Glukhov, Alexander Korotkov
* Update list of combining charactersPeter Eisentraut2019-06-19
| | | | | | | | The list of combining characters to ignore for calculating the display width of a string (used for example by psql) was wildly outdated and incorrect. Discussion: https://www.postgresql.org/message-id/flat/bbb19114-af1e-513b-08a9-61272794bd5c%402ndquadrant.com
* Add XSL stylesheet to fix up SVG filesPeter Eisentraut2019-06-19
| | | | | | | | | | | | | | | | | | | | The SVG output produced by external tools needs some postprocessing. This is implemented by this new XSL stylesheet. Issues are: - SVG produced by Ditaa does not add a viewBox attribute to the svg element, needed to make the image scalable. - SVG produced by Graphviz uses a stroke="transparent" attribute, which is not valid SVG. It appears to mostly work, but FOP complains. Other tweaks can be added over time. This reverts 7dc78d8ef3e62f7e06d7767c63dcede048377b9a and 29046c44f36099f4c979b1491fcf27db2f9184f9, which applied these fixes manually.
* Fix typoMagnus Hagander2019-06-19
| | | | Author: Daniel Gustafsson
* Replace an occurrence of slave with standbyMagnus Hagander2019-06-19
| | | | | | | Commit a1ef920e27ba6ab3602aaf6d6751d8628fac1af8 replaced the use of slave with standby, but overlooked this comment. Author: Daniel Gustafsson
* Remove last references to WAL segment size in MSVC scriptsMichael Paquier2019-06-19
| | | | | | | | fc49e24 has removed the last use of this compile-time variable as WAL segment size is something that can now be set at initdb time, still this commit has forgotten some references to it. Discussion: https://postgr.es/m/20190617073228.GE18917@paquier.xyz
* Fix description of WAL record XLOG_BTREE_META_CLEANUPMichael Paquier2019-06-19
| | | | | | | | | | | | | | | This record uses one metadata buffer and registers some data associated to the buffer, but when parsing the record for its description a direct access to the record data was done, but there is none. This leads usually to an incorrect description, but can also cause crashes like in pg_waldump. Instead, fix things so as the parsing uses the data associated to the metadata block. This is an oversight from 3d92796, so backpatch down to 11. Author: Michael Paquier Description: https://postgr.es/m/20190617013059.GA3153@paquier.xyz Backpatch-through: 11
* Fix memory corruption/crash in ANALYZE.Andres Freund2019-06-18
| | | | | | | | | | | | | | | | This fixes an embarrassing oversight I (Andres) made in 737a292b, namely missing two place where liverows/deadrows were used when converting those variables to pointers, leading to incrementing the pointer, rather than the value. It's not that actually that easy to trigger a crash: One needs tuples deleted by the current transaction, followed by a tuple deleted in another session, all in one page. Which is presumably why this hasn't been noticed before. Reported-By: Steve Singer Author: Steve Singer Discussion: https://postgr.es/m/c7988239-d42c-ddc4-41db-171b23b35e4f@ssinger.info
* Avoid spurious deadlocks when upgrading a tuple lockAlvaro Herrera2019-06-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This puts back reverted commit de87a084c0a5, with some bug fixes. When two (or more) transactions are waiting for transaction T1 to release a tuple-level lock, and transaction T1 upgrades its lock to a higher level, a spurious deadlock can be reported among the waiting transactions when T1 finishes. The simplest example case seems to be: T1: select id from job where name = 'a' for key share; Y: select id from job where name = 'a' for update; -- starts waiting for T1 Z: select id from job where name = 'a' for key share; T1: update job set name = 'b' where id = 1; Z: update job set name = 'c' where id = 1; -- starts waiting for T1 T1: rollback; At this point, transaction Y is rolled back on account of a deadlock: Y holds the heavyweight tuple lock and is waiting for the Xmax to be released, while Z holds part of the multixact and tries to acquire the heavyweight lock (per protocol) and goes to sleep; once T1 releases its part of the multixact, Z is awakened only to be put back to sleep on the heavyweight lock that Y is holding while sleeping. Kaboom. This can be avoided by having Z skip the heavyweight lock acquisition. As far as I can see, the biggest downside is that if there are multiple Z transactions, the order in which they resume after T1 finishes is not guaranteed. Backpatch to 9.6. The patch applies cleanly on 9.5, but the new tests don't work there (because isolationtester is not smart enough), so I'm not going to risk it. Author: Oleksii Kliukin Discussion: https://postgr.es/m/B9C9D7CD-EB94-4635-91B6-E558ACEC0EC3@hintbits.com Discussion: https://postgr.es/m/2815.1560521451@sss.pgh.pa.us
* Prevent Parallel Hash Join for JOIN_UNIQUE_INNER.Thomas Munro2019-06-19
| | | | | | | | | | | | | | WHERE EXISTS (...) queries cannot be executed by Parallel Hash Join with jointype JOIN_UNIQUE_INNER, because there is no way to make a partial plan totally unique. The consequence of allowing such plans was duplicate results from some EXISTS queries. Back-patch to 11. Bug #15857. Author: Thomas Munro Reviewed-by: Tom Lane Reported-by: Vladimir Kriukov Discussion: https://postgr.es/m/15857-d1ba2a64bce0795e%40postgresql.org
* Stamp 12beta2.REL_12_BETA2Tom Lane2019-06-17
|
* Translation updatesPeter Eisentraut2019-06-17
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 1a710c413ce4c4cd081843e563cde256bb95f490
* Fix buffer overflow when processing SCRAM final message in libpqMichael Paquier2019-06-17
| | | | | | | | | | | | | | When a client connects to a rogue server sending specifically-crafted messages, this can suffice to execute arbitrary code as the operating system account used by the client. While on it, fix one error handling when decoding an incorrect salt included in the first message received from server. Author: Michael Paquier Reviewed-by: Jonathan Katz, Heikki Linnakangas Security: CVE-2019-10164 Backpatch-through: 10
* Fix buffer overflow when parsing SCRAM verifiers in backendMichael Paquier2019-06-17
| | | | | | | | | | | | | | | | | | | Any authenticated user can overflow a stack-based buffer by changing the user's own password to a purpose-crafted value. This often suffices to execute arbitrary code as the PostgreSQL operating system account. This fix is contributed by multiple folks, based on an initial analysis from Tom Lane. This issue has been introduced by 68e61ee, so it was possible to make use of it at authentication time. It became more easily to trigger after ccae190 which has made the SCRAM parsing more strict when changing a password, in the case where the client passes down a verifier already hashed using SCRAM. Back-patch to v10 where SCRAM has been introduced. Reported-by: Alexander Lakhin Author: Jonathan Katz, Heikki Linnakangas, Michael Paquier Security: CVE-2019-10164 Backpatch-through: 10
* Fix more typos and inconsistencies in the treeMichael Paquier2019-06-17
| | | | | Author: Alexander Lakhin Discussion: https://postgr.es/m/0a5419ea-1452-a4e6-72ff-545b1a5a8076@gmail.com
* Revert "Avoid spurious deadlocks when upgrading a tuple lock"Alvaro Herrera2019-06-16
| | | | | | | | | | | This reverts commits 3da73d6839dc and de87a084c0a5. This code has some tricky corner cases that I'm not sure are correct and not properly tested anyway, so I'm reverting the whole thing for next week's releases (reintroducing the deadlock bug that we set to fix). I'll try again afterwards. Discussion: https://postgr.es/m/E1hbXKQ-0003g1-0C@gemulon.postgresql.org
* Doc: remove description of commit 23bd3cec6 from v12 release notes.Tom Lane2019-06-16
| | | | | Now that we've back-patched that, it shouldn't be mentioned in v12 anymore.
* Further fix privileges on pg_statistic_ext[_data].Tom Lane2019-06-16
| | | | | | | | | | | | | | | | | We don't need to restrict column privileges on pg_statistic_ext; all of that data is OK to read publicly. What we *do* need to do, which was overlooked by 6cbfb784c, is revoke public read access on pg_statistic_ext_data; otherwise we still have the same security hole we started with. Catversion bump to ensure that installations calling themselves beta2 will have this fix. Diagnosis/correction by Dean Rasheed and Tomas Vondra, but I'm going to go ahead and push this fix ASAP so we get more buildfarm cycles on it. Discussion: https://postgr.es/m/8833.1560647898@sss.pgh.pa.us
* Fix privileges on pg_statistic_ext.tableoidTomas Vondra2019-06-16
| | | | | | | | | The GRANT in system_views allowed SELECT privileges on various columns in the pg_statistic_ext catalog, but tableoid was not included in the list. That made pg_dump fail because it's accessing this column when building the list of extended statistics to dump. Discussion: https://postgr.es/m/8833.1560647898%40sss.pgh.pa.us
* Fix incorrect CREATE STATISTICS example in docsTomas Vondra2019-06-16
| | | | | | | | The example was incorrectly using parantheses around the list of columns, so just drop them. Reported-By: Robert Haas Discussion: https://postgr.es/m/CA%2BTgmoZZEMAqWMAfvLHZnK57SoxOutgvE-ALO94WsRA7zZ7wyQ%40mail.gmail.com
* Add pg_stats_ext view for extended statisticsTomas Vondra2019-06-16
| | | | | | | | | | | | | | | | | | | | | | | Regular per-column statistics are stored in pg_statistics catalog, which is however rather difficult to read, so we also have pg_stats view with a human-reablable version of the data. For extended statistic the catalog was fairly easy to read, so we did not have such human-readable view so far. Commit 9b6babfa2d however did split the catalog into two, which makes querying harder. Furthermore, we want to show the multi-column MCV list in a way similar to per-column stats (and not as a bytea value). This commit introduces pg_stats_ext view, joining the two catalogs and massaging the data to produce human-readable output similar to pg_stats. It also considers RLS and access privileges - the data is shown only when the user has access to all columns the extended statistic is defined on. Bumped CATVERSION due to adding new system view. Author: Dean Rasheed, with improvements by me Reviewed-by: Dean Rasheed, John Naylor Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
* Rework the pg_statistic_ext catalogTomas Vondra2019-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since extended statistic got introduced in PostgreSQL 10, there was a single catalog pg_statistic_ext storing both the definitions and built statistic. That's however problematic when a user is supposed to have access only to the definitions, but not to user data. Consider for example pg_dump on a database with RLS enabled - if the pg_statistic_ext catalog respects RLS (which it should, if it contains user data), pg_dump would not see any records and the result would not define any extended statistics. That would be a surprising behavior. Until now this was not a pressing issue, because the existing types of extended statistic (functional dependencies and ndistinct coefficients) do not include any user data directly. This changed with introduction of MCV lists, which do include most common combinations of values. The easiest way to fix this is to split the pg_statistic_ext catalog into two - one for definitions, one for the built statistic values. The new catalog is called pg_statistic_ext_data, and we're maintaining a 1:1 relationship with the old catalog - either there are matching records in both catalogs, or neither of them. Bumped CATVERSION due to changing system catalog definitions. Author: Dean Rasheed, with improvements by me Reviewed-by: Dean Rasheed, John Naylor Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
* Prefer timezone name "UTC" over alternative spellings.Andrew Gierth2019-06-15
| | | | | | | | | | | | | | | | | | | | | | | | | | tzdb 2019a made "UCT" a link to the "UTC" zone rather than a separate zone with its own abbreviation. Unfortunately, our code for choosing a timezone in initdb has an arbitrary preference for names earlier in the alphabet, and so it would choose the spelling "UCT" over "UTC" when the system is running on a UTC zone. Commit 23bd3cec6 was backpatched in order to address this issue, but that code helps only when /etc/localtime exists as a symlink, and does nothing to help on systems where /etc/localtime is a copy of a zone file (as is the standard setup on FreeBSD and probably some other platforms too) or when /etc/localtime is simply absent (giving UTC as the default). Accordingly, add a preference for the spelling "UTC", such that if multiple zone names have equally good content matches, we prefer that name before applying the existing arbitrary rules. Also add a slightly lower preference for "Etc/UTC"; lower because that preserves the previous behaviour of choosing the shorter name, but letting us still choose "Etc/UTC" over "Etc/UCT" when both exist but "UTC" does not (not common, but I've seen it happen). Backpatch all the way, because the tzdb change that sparked this issue is in those branches too.
* Add pg_dumpall --rows-per-insertAlvaro Herrera2019-06-14
| | | | | | | | | | Commit 7e413a0f82c8 added that option to pg_dump, but neglected to teach pg_dumpall how to pass it along. Repair. Author: Fabien Coelho Reported-by: Peter Eisentraut Reviewed-by: David Rowley Discussion: https://postgr.es/m/45f50c59-ddbb-8cf2-eedb-81003f603528@2ndquadrant.com
* Tweak libpq's PQhost, PQhostaddr, and psql's \connectAlvaro Herrera2019-06-14
| | | | | | | | | | | | | | | | | | | | | | | | Fixes some problems introduced by 6e5f8d489acc: * When reusing conninfo data from the previous connection in \connect, the host address should only be reused if it was specified as hostaddr; if it wasn't, then 'host' is resolved afresh. We were reusing the same IP address, which ignores a possible DNS change as well as any other addresses that the name resolves to than the one that was used in the original connection. * PQhost, PQhostaddr: Don't present user-specified hostaddr when we have an inet_net_ntop-produced equivalent address. The latter has been put in canonical format, which is cleaner (so it produces "127.0.0.1" when given "host=2130706433", for example). * Document the hostaddr-reusing aspect of \connect. * Fix some code comments Author: Fabien Coelho Reported-by: Noah Misch Discussion: https://postgr.es/m/20190527203713.GA58392@gust.leadboat.com
* Silence compiler warningAlvaro Herrera2019-06-14
| | | | Introduced in de87a084c0a5.
* doc: PG 12 relnotes, add mention of single-child optimizationBruce Momjian2019-06-14
| | | | | | | | Add mention of single-child optimization for partitions and UNION ALL. Reported-by: David Rowley Discussion: https://postgr.es/m/CAKJS1f8R8riwBXw==7ijV=UZNuhP+3qXgDBKSiM+=_cTf4mXXw@mail.gmail.com
* postgres_fdw: Fix costing of pre-sorted foreign paths with local stats.Etsuro Fujita2019-06-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit aa09cd242 modified estimate_path_cost_size() so that it reuses cached costs of a basic foreign path for a given foreign-base/join relation when costing pre-sorted foreign paths for that relation, but it incorrectly re-computed retrieved_rows, an estimated number of rows fetched from the remote side, which is needed for costing both the basic and pre-sorted foreign paths. To fix, handle retrieved_rows the same way as the cached costs: store in that relation's fpinfo the retrieved_rows estimate computed for costing the basic foreign path, and reuse it when costing the pre-sorted foreign paths. Also, reuse the rows/width estimates stored in that relation's fpinfo when costing the pre-sorted foreign paths, to make the code consistent. In commit ffab494a4, to extend the costing mentioned above to the foreign-grouping case, I made a change to add_foreign_grouping_paths() to store in a given foreign-grouped relation's RelOptInfo the rows estimate for that relation for reuse, but this patch makes that change unnecessary since we already store the row estimate in that relation's fpinfo, which this patch reuses when costing a foreign path for that relation with the sortClause ordering; remove that change. In passing, fix thinko in commit 7012b132d: in estimate_path_cost_size(), the width estimate for a given foreign-grouped relation to be stored in that relation's fpinfo was reset incorrectly when costing a basic foreign path for that relation with local stats. Apply the patch to HEAD only to avoid destabilizing existing plan choices. Author: Etsuro Fujita Discussion: https://postgr.es/m/CAPmGK17jaJLPDEkgnP2VmkOg=5wT8YQ1CqssU8JRpZ_NSE+dqQ@mail.gmail.com
* docs: PG 12 relnotes, update self-join item to mention ctidBruce Momjian2019-06-13
| | | | | | Reported-by: Robert Haas Discussion: https://postgr.es/m/CA+TgmoY==TZwk-4cM3Usebq1f=j7Hpm1brFbk1v48h45wsWzzg@mail.gmail.com
* docs: PG 12 relnotes, move vacuumdb to the client app sectionBruce Momjian2019-06-13
| | | | | | | | It was previously incorrectly placed in the server application section. Reported-by: Tatsuo Ishii Discussion: https://postgr.es/m/20190526.215341.1023150119477784132.t-ishii@sraoss.co.jp
* Fix typos and inconsistencies in code commentsMichael Paquier2019-06-14
| | | | | Author: Alexander Lakhin Discussion: https://postgr.es/m/dec6aae8-2d63-639f-4d50-20e229fb83e3@gmail.com
* Use OpenSSL-specific ifdefs in sha2.hMichael Paquier2019-06-14
| | | | | | | | | | In order to separate OpenSSL's SHA symbols, this header has been using USE_SSL, which is equivalent to USE_OPENSSL. There is now only one SSL implementation included in the tree, so this works fine, but when adding a new SSL implementation this would run into failures. Author: Daniel Gustafsson Discussion: https://postgr.es/m/0DF29010-CE26-4F51-85A6-9C8ABF5536F9@yesql.se
* Avoid combinatorial explosion in add_child_rel_equivalences().Tom Lane2019-06-13
| | | | | | | | | | | | | | | | | | | | | | | | If an EquivalenceClass member expression includes variables from multiple appendrels, then instead of producing one substituted expression per child relation as intended, we'd create additional child expressions for combinations of children of different appendrels. This happened because the child expressions generated while considering the first appendrel were taken as sources during substitution of the second appendrel, and so on. The extra expressions are useless, and are harmless unless there are too many of them --- but if you have several appendrels with a thousand or so members each, it gets bad fast. To fix, consider only original (non-em_is_child) EC members as candidates to be expanded. This requires the ability to substitute directly from a top parent relation's Vars to those of an indirect descendant relation, but we already have that in adjust_appendrel_attrs_multilevel(). Per bug #15847 from Feike Steenbergen. This is a longstanding misbehavior, but it's only worth worrying about when there are more appendrel children than we've historically considered wise to use. So I'm not going to take the risk of back-patching this. Discussion: https://postgr.es/m/15847-ea3734094bf8ae61@postgresql.org
* Avoid spurious deadlocks when upgrading a tuple lockAlvaro Herrera2019-06-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When two (or more) transactions are waiting for transaction T1 to release a tuple-level lock, and transaction T1 upgrades its lock to a higher level, a spurious deadlock can be reported among the waiting transactions when T1 finishes. The simplest example case seems to be: T1: select id from job where name = 'a' for key share; Y: select id from job where name = 'a' for update; -- starts waiting for X Z: select id from job where name = 'a' for key share; T1: update job set name = 'b' where id = 1; Z: update job set name = 'c' where id = 1; -- starts waiting for X T1: rollback; At this point, transaction Y is rolled back on account of a deadlock: Y holds the heavyweight tuple lock and is waiting for the Xmax to be released, while Z holds part of the multixact and tries to acquire the heavyweight lock (per protocol) and goes to sleep; once X releases its part of the multixact, Z is awakened only to be put back to sleep on the heavyweight lock that Y is holding while sleeping. Kaboom. This can be avoided by having Z skip the heavyweight lock acquisition. As far as I can see, the biggest downside is that if there are multiple Z transactions, the order in which they resume after X finishes is not guaranteed. Backpatch to 9.6. The patch applies cleanly on 9.5, but the new tests don't work there (because isolationtester is not smart enough), so I'm not going to risk it. Author: Oleksii Kliukin Discussion: https://postgr.es/m/B9C9D7CD-EB94-4635-91B6-E558ACEC0EC3@hintbits.com
* Mark ReplicationSlotCtl as PGDLLIMPORT.Tom Lane2019-06-13
| | | | | | | | | | | | | Also MyReplicationSlot, in branches where it wasn't already. This was discussed in the thread that resulted in c572599c6, but for some reason nobody pulled the trigger. Now that we have another request for the same thing, we should just do it. Craig Ringer Discussion: https://postgr.es/m/CAMsr+YFTsq-86MnsNng=mPvjjh5EAbzfMK0ptJPvzyvpFARuRg@mail.gmail.com Discussion: https://postgr.es/m/345138875.20190611151943@cybertec.at
* Fix double-word typosAlvaro Herrera2019-06-13
| | | | | Discussion: https://postgr.es/m/20190612184527.GA24266@alvherre.pgsql Reviewed-by: Michaël Paquier
* doc: PG 12 relnotes: update wording on truncate/vacuum itemBruce Momjian2019-06-13
| | | | | | | | | This item prevents unauthorized locking of relations, and the previous wording was unclear. Reported-by: Michael Paquier Discussion: https://postgr.es/m/20190522072651.GC1278@paquier.xyz
* postgres_fdw: Account for triggers in non-direct remote UPDATE planning.Etsuro Fujita2019-06-13
| | | | | | | | | | | | | | | | | | Previously, in postgresPlanForeignModify, we planned an UPDATE operation on a foreign table so that we transmit only columns that were explicitly targets of the UPDATE, so as to avoid unnecessary data transmission, but if there were BEFORE ROW UPDATE triggers on the foreign table, those triggers might change values for non-target columns, in which case we would miss sending changed values for those columns. Prevent optimizing away transmitting all columns if there are BEFORE ROW UPDATE triggers on the foreign table. This is an oversight in commit 7cbe57c34 which added triggers on foreign tables, so apply the patch all the way back to 9.4 where that came in. Author: Shohei Mochizuki Reviewed-by: Amit Langote Discussion: https://postgr.es/m/201905270152.x4R1q3qi014550@toshiba.co.jp
* Doc: fix bogus example.Tom Lane2019-06-12
| | | | | | | | | This wasn't incorrect SQL, but it was doing cm-to-inch conversion backward, so it might confuse readers. Per bug #15849 from TAKATSUKA Haruka. Discussion: https://postgr.es/m/15849-37ad0c561a836107@postgresql.org
* Doc: improve description of allowed spellings for Boolean input.Tom Lane2019-06-12
| | | | | | | | | | | | | | | | datatype.sgml failed to explain that boolin() accepts any unique prefix of the basic input strings. Indeed it was actively misleading because it called out a few minimal prefixes without mentioning that there were more valid inputs. I also felt that it wasn't doing anybody any favors by conflating SQL key words, valid Boolean input, and string literals containing valid Boolean input. Rewrite in hopes of reducing the confusion. Per bug #15836 from Yuming Wang, as diagnosed by David Johnston. Back-patch to supported branches. Discussion: https://postgr.es/m/15836-656fab055735f511@postgresql.org
* docs: PG 12 relnotes, update btree itemsBruce Momjian2019-06-12
| | | | | | Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wzn-aH4ToZEWR05ELSSp7bO_JMn=sMPfUhNruwVmCXKh-w@mail.gmail.com
* Fix incorrect printing of queries with duplicated join names.Tom Lane2019-06-12
| | | | | | | | | | | | | | | | | Given a query in which multiple JOIN nodes used the same alias (which'd necessarily be in different sub-SELECTs), ruleutils.c would assign the JOIN nodes distinct aliases for clarity ... but then it forgot to print the modified aliases when dumping the JOIN nodes themselves. This results in a dump/reload hazard for views, because the emitted query is flat-out incorrect: Vars will be printed with table names that have no referent. This has been wrong for a long time, so back-patch to all supported branches. Philip Dubé Discussion: https://postgr.es/m/CY4PR2101MB080246F2955FF58A6ED1FEAC98140@CY4PR2101MB0802.namprd21.prod.outlook.com
* doc: Fix grammatical error in partitioning docsDavid Rowley2019-06-13
| | | | | | Reported-by: Amit Langote Discussion: https://postgr.es/m/CA+HiwqGZFkKi0TkBGYpr2_5qrRAbHZoP47AP1BRLUOUkfQdy_A@mail.gmail.com Backpatch-through: 10
* doc: PG 12 relnotes, list added snowball/FTS languagesBruce Momjian2019-06-12
| | | | | | Reported-by: Adrien Nayrat Discussion: https://postgr.es/m/9d6a7515-bcd8-05be-d2a5-e81dc11023cd@anayrat.info
* doc: PG 12 relnotes, merge new SQL partition function itemsBruce Momjian2019-06-12
| | | | | | Reported-by: Andres Freund Discussion: https://postgr.es/m/20190528155823.3e4cezblxjxotq2q@alap3.anarazel.de
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 11:01:38 +0000