Submit news and announcements by Sunday at 3:00pm PST8PDT to david@fetter.org.
-
Fix fuzzy thinking about amcanmulticol versus amcaninclude. These flags should
be independent: in particular an index AM should be able to say that it
supports include columns without necessarily supporting multiple key columns.
The included-columns patch got this wrong, possibly aided by the fact that it
didn't bother to update the documentation. While here, clarify some text
about amcanreturn, which was a little vague about what should happen when
amcanreturn reports that only some of the index columns are returnable. Noted
while reviewing the SP-GiST included-columns patch, which quite incorrectly
(and unsafely) changed SP-GiST to claim amcanmulticol = true as a workaround
for this bug. Backpatch to v11 where included columns were introduced.
https://git.postgresql.org/pg/commitdiff/29d29d652f0be47dc42fa9d667dee5b8e1baa18a
-
Use "true" not "TRUE" in one ICU function call. This was evidently missed in
commit 6337865f3, which generally did s/TRUE/true/ everywhere. It escaped
notice up to now because ICU versions before ICU 68 provided definitions of
"TRUE" and "FALSE" regardless. With ICU 68, it fails to compile. Per report
from Condor. Back-patch to v11 where 6337865f3 came in. (I've not tested v10,
where this call originated, but I imagine it's fine since we defined TRUE in
c.h back then.) Discussion:
https://postgr.es/m/7a6f3336165bfe3ca66abcda7966f9d0@stz-bg.com
https://git.postgresql.org/pg/commitdiff/ad84ecc98d7e2ad81567094b8a6910b5078927a7
-
Do not return NULL for error cases in satisfies_hash_partition(). Since this
function is used as a CHECK constraint condition, returning NULL is tantamount
to returning TRUE, which would have the effect of letting in a row that
doesn't satisfy the hash condition. Admittedly, the cases for which this is
done should be unreachable in practice, but that doesn't make it any less a
bad idea. It also seems like a dartboard was used to decide which error cases
should throw errors as opposed to returning NULL. For the checks for NULL
input values, I just switched it to returning false. There's some argument
that an error would be better; but the case really should be can't-happen in a
generated hash constraint, so it's likely not worth more code for. For the
parent-relation-open-failure case, it seems like we might as well let
relation_open throw an error, instead of having an impossible-to-diagnose
constraint failure. Back-patch to v11 where this code came in. Discussion:
https://postgr.es/m/24067.1605134819@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/4025e6c46620048804467d2ad29d31aa9ba50387
-
Don't Insert() a VFD entry until it's fully built. Otherwise, if FDDEBUG is
enabled, the debugging output fails because it tries to read the fileName,
which isn't set up yet (and should in fact always be NULL). AFAICT, this has
been wrong since Berkeley. Before 96bf88d52, it would accidentally fail to
crash on platforms where snprintf() is forgiving about being passed a NULL
pointer for %s; but the file name intended to be included in the debug output
wouldn't ever have shown up. Report and fix by Greg Nancarrow. Although this
is only visibly broken in custom-made builds, it still seems worth
back-patching to all supported branches, as the FDDEBUG code is pretty useless
as it stands. Discussion:
https://postgr.es/m/CAJcOf-cUDgm9qYtC_B6XrC6MktMPNRby2p61EtSGZKnfotMArw@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/2bd49b493a52f0a21bc3fc51c355963f99ac1a4e
-
Further fixes for CREATE TABLE LIKE: cope with self-referential FKs. Commit
502898192 was too careless about the order of execution of the additional
ALTER TABLE operations generated by expandTableLikeClause. It just stuck them
all at the end, which seems okay for most purposes. But it falls down in the
case where LIKE is importing a primary key or unique index and the outer
CREATE TABLE includes a FOREIGN KEY constraint that needs to depend on that
index. Weird as that is, it used to work, so we ought to keep it working. To
fix, make parse_utilcmd.c insert LIKE clauses between index-creation and
FK-creation commands in the transformed list of commands, and change utility.c
so that the commands generated by expandTableLikeClause are executed
immediately not at the end. One could imagine scenarios where this wouldn't
work either; but currently expandTableLikeClause only makes column default
expressions, CHECK constraints, and indexes, and this ordering seems fine for
those. Per bug #16730 from Sofoklis Papasofokli. Like the previous patch,
back-patch to all supported branches. Discussion:
https://postgr.es/m/16730-b902f7e6e0276b30@postgresql.org
https://git.postgresql.org/pg/commitdiff/97390fe8a6e96a153e59b0180f4303acaeb75b84
-
Remove undocumented IS [NOT] OF syntax. This feature was added a long time
ago, in 7c1e67bd5 and eb121ba2c, but never documented in any user-facing way.
(Documentation added in 6126d3e70 was commented out almost immediately, in
8272fc3f7.) That's because, while this syntax is defined by SQL:99, our
implementation is only vaguely related to the standard's semantics. The
standard appears to intend a run-time not parse-time test, and it definitely
intends that the test should understand subtype relationships. No one has
stepped up to fix that in the intervening years, but people keep coming across
the code and asking why it's not documented. Let's just get rid of it: if
anyone ever wants to make it work per spec, they can easily recover whatever
parts of this code are still of value from our git history. If there's anyone
out there who's actually using this despite its undocumented status, they can
switch to using pg_typeof() instead, eg. "pg_typeof(something) =
'mytype'::regtype". That gives essentially the same semantics as what our IS
OF code did. (We didn't have that function last time this was discussed, or we
would have ripped out IS OF then.) Discussion:
https://postgr.es/m/CAKFQuwZ2pTc-DSkOiTfjauqLYkNREeNZvWmeg12Q-_69D+sYZA@mail.gmail.com
Discussion: https://postgr.es/m/BAY20-F23E9F2B4DAB3E4E88D3623F99B0@phx.gbl
Discussion: https://postgr.es/m/3E7CF81D.1000203@joeconway.com
https://git.postgresql.org/pg/commitdiff/926fa801ac9eb54c5275472271ec63a059904698
-
On macOS, use -isysroot in link steps as well as compile steps. We previously
put the -isysroot switch only into CPPFLAGS, theorizing that it was only
needed to find the right copies of include files. However, it seems that we
also need to use it while linking programs, to find the right stub ".tbd"
files for libraries. We got away without that up to now, but apparently that
was mostly luck. It may also be that failures are only observed when the
Xcode version is noticeably out of sync with the host macOS version; the case
that's prompting action right now is that builds fail when using latest Xcode
(12.2) on macOS Catalina, even though it's fine on Big Sur. Hence, add
-isysroot to LDFLAGS as well. (It seems that the more common practice is to
put it in CFLAGS, whence it'd be included at both compile and link steps.
However, we can't mess with CFLAGS in the platform template file without
confusing configure's logic for choosing default CFLAGS.) This should be
back-patched, but first let's see if the buildfarm likes it on HEAD. Report
and patch by James Hilliard (some cosmetic mods by me) Discussion:
https://postgr.es/m/20201120003314.20560-1-james.hilliard1@gmail.com
https://git.postgresql.org/pg/commitdiff/49407dc32a2931550e4ff1dea314b6a25afdfc35
-
Extend the geometric regression test cases a little. Add another edge-case
value to "point_tbl", and add a test for the line(point, point) function.
Some of the behaviors exposed here are wrong, but the idea of committing this
separately is to memorialize what we were getting, and to allow easier
inspection of the behavior changes caused by upcoming patches. Kyotaro
Horiguchi (line() test added by me) Discussion:
https://postgr.es/m/CAGf+fX70rWFOk5cd00uMfa__0yP+vtQg5ck7c2Onb-Yczp0URA@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/a45272b25d6fc8f96793623545fc1f836ac39d94
-
Fix FPeq() and friends to get the right answers for infinities.
"FPeq(infinity, infinity)" returned false, on account of getting NaN when it
subtracts the two inputs. Fix that by adding a separate check for exact
equality. FPle() and FPge() similarly got the wrong answer for two
like-signed infinities. In those cases, we can just rearrange the comparisons
to avoid potentially subtracting infinities. While the sibling functions
FPne() etc accidentally gave the right answers even with the internal NaN
results, it seems best to make similar adjustments to them to avoid depending
on this. FPeq() has to be converted to an inline function to avoid double
evaluations of its arguments, and I did the same for the others just for
consistency. In passing, make the handling of NaN cases in line_eq() and
point_eq_point() simpler and easier to reason about, and perhaps faster. This
results in just one visible regression test change: slope() now gives DBL_MAX
for two inputs of (inf,1e300), which is consistent with what it does for
(1e300,inf), so that seems like a bug fix. Discussion:
https://postgr.es/m/CAGf+fX70rWFOk5cd00uMfa__0yP+vtQg5ck7c2Onb-Yczp0URA@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/8597a48d01b6cc0b09ff626253ac93c67e5516d5
-
In geo_ops.c, represent infinite slope as Infinity, not DBL_MAX. Since we're
assuming IEEE floats these days, there seems little reason not to do this. It
has the advantage that when the slope is computed as infinite due to the
presence of Inf coordinates, we get saner behavior than before from
line_construct(), and thence also in some dependent operations such as finding
the closest point. Also fix line_construct() to special-case slope zero. The
previous coding got the right answer in most cases, but it could compute C as
NaN when the point has Inf coordinates. Discussion:
https://postgr.es/m/CAGf+fX70rWFOk5cd00uMfa__0yP+vtQg5ck7c2Onb-Yczp0URA@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/9fe649ea295f00baf6d0f0c1f9b0cb1298f64fb9
-
Relax INSERT privilege requirement for CTAS and matviews WITH NO DATA. When
specified, WITH NO DATA does not insert any data into the relation created, so
skip checking for the insert permissions. With WITH DATA or WITH NO DATA, it
is always required for the user to have CREATE privileges on the schema
targeted for the relation. Note that plain CREATE TABLE AS or CREATE
MATERIALIZED VIEW queries have begun to work accidentally without INSERT
privilege checks as of 874fe3ae, while using EXECUTE or EXPLAIN ANALYZE would
fail with the ACL check, so this makes the behavior for all the command
flavors consistent with each other. This is arguably a bug fix, but there
have been no complaints about the current behavior either so stable branches
are not changed. While on it, document properly the privileges requirements
for each commands with more tests for all the scenarios possible, and avoid a
useless bulk-insert allocation when using WITH NO DATA. Author: Bharath
Rupireddy Reviewed-by: Anastasia Lubennikova, Michael Paquier Discussion:
https://postgr.es/m/CALj2ACWc3N8j0_9nMPz9wcAUnVcdKHzFdDZJ3hVFNEbqtcyG9w@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/846005e4f3829c3eafe1f8441b80ff90657d0a29
-
Add tab completion for CREATE [OR REPLACE] TRIGGER in psql. 92bf7e2 has added
support for this grammar. Author: Noriyoshi Shinoda Discussion:
https://postgr.es/m/TU4PR8401MB115244623CF4724DCA0D507FEEE30@TU4PR8401MB1152.NAMPRD84.PROD.OUTLOOK.COM
https://git.postgresql.org/pg/commitdiff/bf0aa7c4b83bcf3116c5a3c191bbc677ab3beb59
-
Improve failure detection with array parsing in pg_dump. Similarly to 3636efa,
the checks done in pg_dump when parsing array values from catalogs have been
too lax. Under memory pressure, it could be possible, though very unlikely,
to finish with dumps that miss some data like: - Statistics for indexes -
Run-time configuration of functions - Configuration of extensions -
Publication list for a subscription No backpatch is done as this is not going
to be a problem in practice. For example, if an OOM causes an array parsing to
fail, a follow-up code path of pg_dump would most likely complain with an
allocation failure due to the memory pressure. Author: Michael Paquier
Reviewed-by: Daniel Gustafsson Discussion:
https://postgr.es/m/20201111061319.GE2276@paquier.xyz
https://git.postgresql.org/pg/commitdiff/13b58f8934e6252868231c3493d49b8c2b363e5d
-
Remove INSERT privilege check at table creation of CTAS and matview. As per
discussion with Peter Eisentraunt, the SQL standard specifies that any tuple
insertion done as part of CREATE TABLE AS happens without any extra ACL check,
so it makes little sense to keep a check for INSERT privileges when using WITH
DATA. Materialized views are not part of the standard, but similarly, this
check can be confusing as this refers to an access check on a table created
within the same command as the one that would insert data into this table.
This commit removes the INSERT privilege check for WITH DATA, the default,
that 846005e removed partially, but only for WITH NO DATA. Author: Bharath
Rupireddy Discussion:
https://postgr.es/m/d049c272-9a47-d783-46b0-46665b011598@enterprisedb.com
https://git.postgresql.org/pg/commitdiff/878f3a19c6c8ff197e4a33f51d921a4abafcc494