From: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Cc: | lukas(dot)eder(at)gmail(dot)com |
Subject: | BUG #15344: pg_proc.proisagg was removed incompatibly in PostgreSQL 11 |
Date: | 2018-08-21 14:23:45 |
Message-ID: | 153486142520.1370.12035528830969343708@wrigleys.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 15344
Logged by: Lukas Eder
Email address: lukas(dot)eder(at)gmail(dot)com
PostgreSQL version: 11beta2
Operating system: Debian
Description:
When comparing the current version (10) [1] and the developer version (11)
[2] of the pg_proc documentation, then it can be seen that the
pg_proc.proisagg column was removed backwards incompatibly. The
documentation states for [1]:
> The table contains data for aggregate functions as well as plain
functions. If proisagg is true, there should be a matching row in
pg_aggregate.
And for [2]:
> If prokind indicates that the entry is for an aggregate function, there
should be a matching row in pg_aggregate.
While I appreciate that an encoded enumeration is more powerful than a
simple boolean value, I think it would have been better if this change had
been done backwards compatibly. For example, there could still be a
pg_proc.proisagg column that defaults to (prokind = 'a').
[1] https://www.postgresql.org/docs/10/static/catalog-pg-proc.html
[2] https://www.postgresql.org/docs/11/static/catalog-pg-proc.html
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-08-21 14:28:21 | Re: BUG #15344: pg_proc.proisagg was removed incompatibly in PostgreSQL 11 |
Previous Message | Peter Eisentraut | 2018-08-21 13:01:49 | Re: BUG #15343: Segmentation fault using pg_dump with --exclude-table if table contains identity column |