== PostgreSQL Weekly News - October 22 2017 ==

== PostgreSQL Weekly News - October 22 2017 ==

PotgreSQL Conference 2017 Japan will be held on November 3rd, 2017 in Tokyo.
https://www.postgresql.jp/events/jpug-pgcon2017

PGConf.ASIA 2017 will take place on December 4-6 2017 in Akihabara, Tokyo,
Japan. Registration is open at http://eventregist.com/e/PGConfASIA2017?lang=en_US
http://www.pgconf.asia/EN/2017/

FOSDEM PGDay 2018, a one day conference held before the main FOSDEM event will
be held in Brussels, Belgium, on Feb 2nd, 2018.
https://2018.fosdempgday.org/

== PostgreSQL Product News ==

PostgresDAC 3.3.0, a direct access component suite for PostgreSQL, released.
http://microolap.com/products/connectivity/postgresdac/download/

PGConf US 2018 will be held in Jersey City, NJ, USA April 16-20, 2018. The CfP
will be open until January 22, 2018. Speaker notification: January 31, 2018.
https://pgconf.org/conferences/2018

Pgpool-II 3.7 beta1 released.
http://www.pgpool.net/docs/pgpool-II-3.7.0/doc/en/html/release-3-7.html

PostGIS 2.2.6, 2.3.4, and 2.4.1, the industry standard geographic information
system package for PostgreSQL, released.
http://postgis.net/2017/10/18/postgis-patches/

== PostgreSQL Jobs for October ==

http://archives.postgresql.org/pgsql-jobs/2017-10/

== PostgreSQL Local ==

PostgreSQL Conference Europe 2017 will be held on October 24-27, 2017 in the
Warsaw Marriott Hotel, in Warsaw, Poland.
https://2017.pgconf.eu/

pgday.Seoul 2017 will be held in Seoul, South Korea on November 4, 2017.
Korean language information is here:
http://pgday.postgresql.kr/

2ndQuadrant PostgreSQL Conference 2017 (2Q PGConf, for short) will be hosted on
November 6th & 7th in New York City, and November 9th in Chicago.
http://www.2qpgconf.com/

PGConf Local: Seattle will be held November 13 - 14, 2017.
https://www.pgconf.us/#Seattle2017

PGDay Australia 2017 will be held on November 17 in Melbourne.
http://2017.pgday.com.au/

PostgreSQL Session will take place November 17th, 2017, in Paris, France.
http://www.postgresql-sessions.org/en/9/start

PGDAY Brasilia 2017 will take place December 2, 2017. The CfP
is open at
http://www.pgdaybrasilia.com.br/submissao-de-palestra/

PGConf Local: Austin will be held December 4 - 5, 2017. Call for Papers is
now open at https://www.pgconf.us/conferences/Austin2017

PGConf.ASIA 2017 will take place on December 4-6 2017 in Akihabara, Tokyo,
Japan.
http://www.pgconf.asia/EN/2017/

PGConf India 2018 will be on February 22-23, 2018 in Bengaluru, Karnataka.
Proposals are due via https://goo.gl/forms/F9hRjOIsaNasVOAz2 by October 31st, 2017.
http://pgconf.in/

PostgreSQL(at)SCaLE is a two day, two track event which takes place on
March 8-9, 2018, at Pasadena Convention Center, as part of SCaLE 16X.
The CfP is open through October 31, 2017 at
http://www.socallinuxexpo.org/scale/16x/cfp

PGConf APAC 2018 will be held in Singapore March 22-24, 2018. The CfP is open
at http://2018.pgconfapac.org/cfp through December 4, 2017.
http://2018.pgconfapac.org/

== PostgreSQL in the News ==

Planet PostgreSQL: http://planet.postgresql.org/

PostgreSQL Weekly News is brought to you this week by David Fetter

Submit news and announcements by Sunday at 3:00pm EST5EDT. Please send English
language ones to david(at)fetter(dot)org, German language to pwn(at)pgug(dot)de, Italian
language to pwn(at)itpug(dot)org(dot)

== Applied Patches ==

Tom Lane pushed:

- Restore nodeAgg.c's ability to check for improperly-nested aggregates. While
poking around in the aggregate logic, I noticed that commit 8ed3f11bb broke
the logic in nodeAgg.c that purports to detect nested aggregates, by moving
initialization of regular aggregate argument expressions out of the code
segment that checks for that. You could argue that this check is unnecessary,
but it's not much code so I'm inclined to keep it as a backstop against parser
and planner bugs. However, there's certainly zero value in checking only some
of the subexpressions. We can make the check complete again, and as a bonus
make it a good deal more bulletproof against future mistakes of the same ilk,
by moving it out to the outermost level of ExecInitAgg. This means we need to
check only once per Agg node not once per aggregate, which also seems like a
good thing --- if the check does find something wrong, it's not urgent that we
report it before the plan node initialization finishes. Since this requires
remembering the original length of the aggs list, I deleted a long-obsolete
stanza that changed numaggs from 0 to 1. That's so old it predates our
decision that palloc(0) is a valid operation, in (digs...) 2004, see commit
24a1e20f1. In passing improve a few comments. Back-patch to v10, just in
case.
https://git.postgresql.org/pg/commitdiff/5fc438fb256ce83248feaf60e22e0919b76e3c7b

- Repair breakage of aggregate FILTER option. An aggregate's input
expression(s) are not supposed to be evaluated at all for a row where its
FILTER test fails ... but commit 8ed3f11bb overlooked that requirement.
Reshuffle so that aggregates having a filter clause evaluate their arguments
separately from those without. This still gets the benefit of doing only one
ExecProject in the common case of multiple Aggrefs, none of which have
filters. While at it, arrange for filter clauses to be included in the common
ExecProject evaluation, thus perhaps buying a little bit even when there are
filters. Back-patch to v10 where the bug was introduced. Discussion:
https://postgr.es/m/30065.1508161354@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/c3dfe0fec01469b8a7de327303cad50ba8ed338a

- Allow the built-in ordered-set aggregates to share transition state. The
built-in OSAs all share the same transition function, so they can share
transition state as long as the final functions cooperate to not do the sort
step more than once. To avoid running the tuplesort object in randomAccess
mode unnecessarily, add a bit of infrastructure to nodeAgg.c to let the
aggregate functions find out whether the transition state is actually being
shared or not. This doesn't work for the hypothetical aggregates, since those
inject a hypothetical row that isn't traceable to the shared input state. So
they remain marked aggfinalmodify = 'w'. Discussion:
https://postgr.es/m/CAB4ELO5RZhOamuT9Xsf72ozbenDLLXZKSk07FiSVsuJNZB861A@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/be0ebb65f51225223421df6e10eb6e87fc8264d7

- Treat aggregate direct arguments as per-agg data not per-trans data. There is
no reason to insist that direct arguments must match before we can merge
transition states of two aggregate calls. They're only used during the
finalfn call, so we can treat them as like the finalfn itself. This allows,
eg, merging of select percentile_cont(0.25) within group (order by a),
percentile_disc(0.5) within group (order by a) from ... This didn't matter
(and could not have been tested) before we allowed state merging of OSAs
otherwise. Discussion:
https://postgr.es/m/CAB4ELO5RZhOamuT9Xsf72ozbenDLLXZKSk07FiSVsuJNZB861A@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/cf5ba7c30c0428f5ff49197ec1e0f052035300d6

- Fix incorrect handling of CTEs and ENRs as DML target relations.
setTargetTable threw an error if the proposed target RangeVar's relname
matched any visible CTE or ENR. This breaks backwards compatibility in the
CTE case, since pre-v10 we never looked for a CTE here at all, so that CTE
names did not mask regular tables. It does seem like a good idea to throw an
error for the ENR case, though, thus causing ENRs to mask tables for this
purpose; ENRs are new in v10 so we're not breaking existing code, and we may
someday want to allow them to be the targets of DML. To fix that, replace use
of getRTEForSpecialRelationTypes, which was overkill anyway, with use of
scanNameSpaceForENR. A second problem was that the check neglected to verify
null schemaname, so that a CTE or ENR could incorrectly be thought to match a
qualified RangeVar. That happened because getRTEForSpecialRelationTypes
relied on its caller to have checked for null schemaname. Even though the one
remaining caller got it right, this is obviously bug-prone, so move the check
inside getRTEForSpecialRelationTypes. Also, revert commit 18ce3a4ab's
extremely poorly thought out decision to add a NULL return case to
parserOpenTable --- without either documenting that or adjusting any of the
callers to check for it. The current bug seems to have arisen in part due to
working around that bad idea. In passing, remove the one-line shim functions
transformCTEReference and transformENRReference --- they don't seem to be
adding any clarity or functionality. Per report from Hugo Mercier (via Julien
Rouhaud). Back-patch to v10 where the bug was introduced. Thomas Munro, with
minor editing by me Discussion:
https://postgr.es/m/CAOBaU_YdPVH+PTtiKSSLOiiW3mVDYsnNUekK+XPbHXiP=wrFLA@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/7421f4b89a90e1fa45751dd1cbc4e8d4ca1cba5e

- Fix incorrect handling of CTEs and ENRs as DML target relations.
setTargetTable threw an error if the proposed target RangeVar's relname
matched any visible CTE or ENR. This breaks backwards compatibility in the
CTE case, since pre-v10 we never looked for a CTE here at all, so that CTE
names did not mask regular tables. It does seem like a good idea to throw an
error for the ENR case, though, thus causing ENRs to mask tables for this
purpose; ENRs are new in v10 so we're not breaking existing code, and we may
someday want to allow them to be the targets of DML. To fix that, replace use
of getRTEForSpecialRelationTypes, which was overkill anyway, with use of
scanNameSpaceForENR. A second problem was that the check neglected to verify
null schemaname, so that a CTE or ENR could incorrectly be thought to match a
qualified RangeVar. That happened because getRTEForSpecialRelationTypes
relied on its caller to have checked for null schemaname. Even though the one
remaining caller got it right, this is obviously bug-prone, so move the check
inside getRTEForSpecialRelationTypes. Also, revert commit 18ce3a4ab's
extremely poorly thought out decision to add a NULL return case to
parserOpenTable --- without either documenting that or adjusting any of the
callers to check for it. The current bug seems to have arisen in part due to
working around that bad idea. In passing, remove the one-line shim functions
transformCTEReference and transformENRReference --- they don't seem to be
adding any clarity or functionality. Per report from Hugo Mercier (via Julien
Rouhaud). Back-patch to v10 where the bug was introduced. Thomas Munro, with
minor editing by me Discussion:
https://postgr.es/m/CAOBaU_YdPVH+PTtiKSSLOiiW3mVDYsnNUekK+XPbHXiP=wrFLA@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/7421f4b89a90e1fa45751dd1cbc4e8d4ca1cba5e

- Fix incorrect link in v10 release notes. As noted by M. Justin. Also, to
keep the HEAD and REL_10 versions of release-10.sgml in sync, back-patch the
effects of c29c57890 on that file. We have a bigger problem there though :-(
Discussion:
https://postgr.es/m/CALtA7pmsQyTTD3fC2rmfUWgfivv5sCJJ84PHY0F_5t_SRc07Qg@mail.gmail.com
Discussion:
https://postgr.es/m/6d137bd0-eef6-1d91-d9b8-1a5e9195a899@2ndquadrant.com
https://git.postgresql.org/pg/commitdiff/e250c8c8408a1c068285df210a7ceff68c421b3b

- Fix misimplementation of typcache logic for extended hashing. The previous
coding would report that an array type supports extended hashing if its
element type supports regular hashing. This bug is only latent at the moment,
since AFAICS there is not yet any code that depends on checking presence of
extended-hashing support to make any decisions. (And in any case it wouldn't
matter unless the element type has only regular hashing, which isn't true of
any core data type.) But that doesn't make it less broken. Extend the
cache_array_element_properties infrastructure to check this properly.
https://git.postgresql.org/pg/commitdiff/a8f1efc8ace228b5258ee7d06eace923007072c4

- Fix typcache's failure to treat ranges as container types. Like the similar
logic for arrays and records, it's necessary to examine the range's subtype to
decide whether the range type can support hashing. We can omit checking the
subtype for btree-defined operations, though, since range subtypes are
required to have those operations. (Possibly that simplification for btree
cases led us to overlook that it does not apply for hash cases.) This is only
an issue if the subtype lacks hash support, which is not true of any built-in
range type, but it's easy to demonstrate a problem with a range type over, eg,
money: you can get a "could not identify a hash function" failure when the
planner is misled into thinking that hash join or aggregation would work.
This was born broken, so back-patch to all supported branches.
https://git.postgresql.org/pg/commitdiff/36ea99c84d856177ec307307788a279cc600566e

Álvaro Herrera pushed:

- Rework DefineIndex relkind check. Simplify coding using a switch rather than
nested if tests. Author: Álvaro Reviewed-by: Robert Haas, Amit Langote,
Michaël Paquier Discussion:
https://postgr.es/m/20171013163820.pai7djcaxrntaxtn@alvherre.pgsql
https://git.postgresql.org/pg/commitdiff/60a1d96ed7ba0930024af696e1fb209a030b6c42

- REASSIGN OWNED BY doc: s/privileges/membership/. Reported by: David G.
Johnston Discussion:
https://postgr.es/m/CAKFQuwajWqjqEL9xc1xnnmTyBg32EdAZKJXijzigbosGSs_vag@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/6ecabead4b5993c42745f2802d857b1a79f48bf9

- Make release notes aware that --xlog-method was renamed. Author: David G.
Johnston Discussion:
https:/postgr.es/m/CAKFQuwaCsb-OKOjQXGeN0R7byxiRWvr7OtyKDbJoYgiF2vBG4Q@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/f5b73093339d965744607b786d7c34bf8f430935

- Make OWNER TO subcommand mention consistent. We say 'OWNER TO' in the
synopsis; let's use that form elsewhere. There is a paragraph in the <note>
section that refers to various subcommands very loosely (including OWNER); I
didn't think it was an improvement to change that one. This is a fairly
inconsequential change, so no backpatch. Author: Amit Langote Discussion:
https://postgr.es/m/69ec7b51-03e5-f523-95ce-c070ee790e70@lab.ntt.co.jp
https://git.postgresql.org/pg/commitdiff/bf54c0f05c0a58db17627724a83e1b6d4ec2712c

- Add more tests for reloptions. This is preparation for a future patch to
extensively change how reloptions work. Author: Nikolay Shaplov Reviewed-by:
Michael Paquier Discussion: https://postgr.es/m/2615372.orqtEn8VGB@x200m
https://git.postgresql.org/pg/commitdiff/4b95cc1dc36c9d1971f757e9b519fcc442833f0e

Peter Eisentraut pushed:

- Exclude flex-generated code from coverage testing. Flex generates a lot of
functions that are not actually used. In order to avoid coverage figures
being ruined by that, mark up the part of the .l files where the generated
code appears by lcov exclusion markers. That way, lcov will typically only
reported on coverage for the .l file, which is under our control, but not for
the .c file. Reviewed-by: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
https://git.postgresql.org/pg/commitdiff/421167362242ce1fb46d6d720798787e7cd65aad

- Don't use SGML empty tags. For DocBook XML compatibility, don't use SGML
empty tags (</>) anymore, replace by the full tag name. Add a warning option
to catch future occurrences. Alexander Lakhin, Jürgen Purtz
https://git.postgresql.org/pg/commitdiff/c29c578908dc0271eeb13a4014e54bff07a29c05

- UCS_to_most.pl: Process encodings in sorted order. Otherwise the order
depends on the Perl hash implementation, making it cumbersome to scan the
output when debugging.
https://git.postgresql.org/pg/commitdiff/927e1ee2cb74e3bc49454dfa181dcce83b70d371

- Convert SGML IDs to lower case. IDs in SGML are case insensitive, and we have
accumulated a mix of upper and lower case IDs, including different variants of
the same ID. In XML, these will be case sensitive, so we need to fix up those
differences. Going to all lower case seems most straightforward, and the
current build process already makes all anchors and lower case anyway during
the SGML->XML conversion, so this doesn't create any difference in the output
right now. A future XML-only build process would, however, maintain any mixed
case ID spellings in the output, so that is another reason to clean this up
beforehand. Author: Alexander Lakhin <exclusion(at)gmail(dot)com>
https://git.postgresql.org/pg/commitdiff/1ff01b3902cbf5b22d1a439014202499c21b2994

- Convert another SGML ID to lower case. The mostly automated conversion in
1ff01b3902cbf5b22d1a439014202499c21b2994 missed this one because of the
unusual whitespace.
https://git.postgresql.org/pg/commitdiff/7c981590c2e8149a88f6b53829770e2277336879

Magnus Hagander pushed:

- Fix typo in release notes. Spotted by Piotr Stefaniak
https://git.postgresql.org/pg/commitdiff/bcf2e5ceb0998318deb36911b13677e88d45c8b4

- Fix typo. Masahiko Sawada
https://git.postgresql.org/pg/commitdiff/275c4be19deec4288c303cc9ba3a3540bd1b8f5f

- Fix typos. David Rowley
https://git.postgresql.org/pg/commitdiff/752871b6de9b4c7d2c685a059adb55887e169201

Robert Haas pushed:

- pg_stat_statements: Add a comment about the dangers of padding bytes.
Inspired by a patch from Julien Rouhaud, but I reworded it. Discussion:
http://postgr.es/m/CAOBaU_a8AH8=ypfqgHnDYu06ts+jWTUgh=VgCxA3yNV-K10j9w@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/2959213bf33cf7d2d1fc0b46c67d36254ffe043f

== Pending Patches ==

Amit Khandekar sent in another revision of a patch to enable updates of
partition keys to move tuples to the corresponding partition.

Ashutosh Bapat sent in a patch to ignore dropped columns in set_append_rel_size().

Thomas Munro sent in a patch to ensure that EOF doesn't count as a temporary
buffer read in EXPLAIN.

Eric Radman sent in two revisions of a patch to add a
recovery_min_apply_delay_reconnect recovery option.

Eiji Seki sent in a patch to fix a typo in blvacuum.c.

Thomas Munro sent in a patch to add a GUC to control whether Gather runs
subplans.

Masahiko Sawada sent in another revision of a patch to implement block level
parallel vacuum.

Masahiko Sawada sent in another revision of a patch to enable custom
initialization for pgbench.

Badrul Chowdhury sent in another revision of a patch to enable wire protocol
version negotiation.

Amit Langote sent in another revision of a patch to add new tests for
partition-pruning, make some planner-side changes for same, implement
get_partitions_from_clauses, make some interface changes for
partition_bound_{cmp/bsearch}, and implement get_partitions_for_keys.

Amit Khandekar sent in another revision of a patch to implement parallel append.

Nico Williams sent in another revision of a patch to add an ALWAYS DEFERRED
option for constraints and constraint triggers.

Tomas Vondra sent in a patch to implement BRIN Bloom indexes.

Tom Lane sent in another revision of a patch to allow creating DOMAINs over
composite types.

Yura Sokolov sent in another revision of a patch to fix performance degradation
of contended LWLocks on NUMA.

Aleksandr Parfenov sent in two revisions of a patch to create a flexible
configuration system for full-text search.

Kyotaro HORIGUCHI sent in another revision of a patch to enable asynchrounous
execution in core and implement same in the PostgreSQL foreign data wrapper.

Fabien COELHO sent in another revision of a patch to enable pgbench to use more
operators and functions.

Fabien COELHO sent in another revision of a patch to enable pgbench to store
select results into variables.

Peter Geoghegan sent in a patch to add a Bloom filter data structure
implementation and use same to add amcheck verification of indexes against the
heap.

Robert Haas sent in another revision of a patch to refactor handling of database
attributes between pg_dump and pg_dumpall.

Andrey Borodin sent in a patch to create cube opclass without
compress/decompress.