[COMMITTERS] pgsql: Dept of second thoughts: keep aliasp_item in sync with tlistitem

Dept of second thoughts: keep aliasp_item in sync with tlistitem. Commit d5b760ecb wasn't quite right, on second thought: if the caller didn't ask for column names then it would happily emit more Vars than if the caller did ask for column names. This is surely not a good idea. Advance the

[COMMITTERS] pgsql: Dept of second thoughts: keep aliasp_item in sync with tlistitem

Dept of second thoughts: keep aliasp_item in sync with tlistitem. Commit d5b760ecb wasn't quite right, on second thought: if the caller didn't ask for column names then it would happily emit more Vars than if the caller did ask for column names. This is surely not a good idea. Advance the

[COMMITTERS] pgsql: Dept of second thoughts: keep aliasp_item in sync with tlistitem

Dept of second thoughts: keep aliasp_item in sync with tlistitem. Commit d5b760ecb wasn't quite right, on second thought: if the caller didn't ask for column names then it would happily emit more Vars than if the caller did ask for column names. This is surely not a good idea. Advance the

[COMMITTERS] pgsql: Dept of second thoughts: keep aliasp_item in sync with tlistitem

Dept of second thoughts: keep aliasp_item in sync with tlistitem. Commit d5b760ecb wasn't quite right, on second thought: if the caller didn't ask for column names then it would happily emit more Vars than if the caller did ask for column names. This is surely not a good idea. Advance the

[COMMITTERS] pgsql: Dept of second thoughts: keep aliasp_item in sync with tlistitem

Dept of second thoughts: keep aliasp_item in sync with tlistitem. Commit d5b760ecb wasn't quite right, on second thought: if the caller didn't ask for column names then it would happily emit more Vars than if the caller did ask for column names. This is surely not a good idea. Advance the

[COMMITTERS] pgsql: Dept of second thoughts: keep aliasp_item in sync with tlistitem

Dept of second thoughts: keep aliasp_item in sync with tlistitem. Commit d5b760ecb wasn't quite right, on second thought: if the caller didn't ask for column names then it would happily emit more Vars than if the caller did ask for column names. This is surely not a good idea. Advance the

[COMMITTERS] pgsql: Dept of second thoughts: keep aliasp_item in sync with tlistitem

Dept of second thoughts: keep aliasp_item in sync with tlistitem. Commit d5b760ecb wasn't quite right, on second thought: if the caller didn't ask for column names then it would happily emit more Vars than if the caller did ask for column names. This is surely not a good idea. Advance the

[COMMITTERS] pgsql: Fix crash when columns have been added to the end of a view.

Fix crash when columns have been added to the end of a view. expandRTE() supposed that an RTE_SUBQUERY subquery must have exactly as many non-junk tlist items as the RTE has column aliases for it. This was true at the time the code was written, and is still true so far as parse analysis is

[COMMITTERS] pgsql: Fix crash when columns have been added to the end of a view.

Fix crash when columns have been added to the end of a view. expandRTE() supposed that an RTE_SUBQUERY subquery must have exactly as many non-junk tlist items as the RTE has column aliases for it. This was true at the time the code was written, and is still true so far as parse analysis is

[COMMITTERS] pgsql: Fix crash when columns have been added to the end of a view.

Fix crash when columns have been added to the end of a view. expandRTE() supposed that an RTE_SUBQUERY subquery must have exactly as many non-junk tlist items as the RTE has column aliases for it. This was true at the time the code was written, and is still true so far as parse analysis is

[COMMITTERS] pgsql: Fix crash when columns have been added to the end of a view.

Fix crash when columns have been added to the end of a view. expandRTE() supposed that an RTE_SUBQUERY subquery must have exactly as many non-junk tlist items as the RTE has column aliases for it. This was true at the time the code was written, and is still true so far as parse analysis is

[COMMITTERS] pgsql: Fix crash when columns have been added to the end of a view.

Fix crash when columns have been added to the end of a view. expandRTE() supposed that an RTE_SUBQUERY subquery must have exactly as many non-junk tlist items as the RTE has column aliases for it. This was true at the time the code was written, and is still true so far as parse analysis is

[COMMITTERS] pgsql: Fix crash when columns have been added to the end of a view.

Fix crash when columns have been added to the end of a view. expandRTE() supposed that an RTE_SUBQUERY subquery must have exactly as many non-junk tlist items as the RTE has column aliases for it. This was true at the time the code was written, and is still true so far as parse analysis is

[COMMITTERS] pgsql: Fix crash when columns have been added to the end of a view.

Fix crash when columns have been added to the end of a view. expandRTE() supposed that an RTE_SUBQUERY subquery must have exactly as many non-junk tlist items as the RTE has column aliases for it. This was true at the time the code was written, and is still true so far as parse analysis is

[COMMITTERS] pgsql: Allow parallel query for prepared statements with generic plans.

Allow parallel query for prepared statements with generic plans. This was always intended to work, but due to an oversight in max_parallel_hazard_walker, it didn't. In testing, we missed the fact that it was only working for custom plans, where the parameter value has been substituted for the

[COMMITTERS] pgsql: Rethink the dependencies recorded for FieldSelect/FieldStore nod

Rethink the dependencies recorded for FieldSelect/FieldStore nodes. On closer investigation, commits f3ea3e3e8 et al were a few bricks shy of a load. What we need is not so much to lock down the result type of a FieldSelect, as to lock down the existence of the column it's trying to extract.

[COMMITTERS] pgsql: Rethink the dependencies recorded for FieldSelect/FieldStore nod

Rethink the dependencies recorded for FieldSelect/FieldStore nodes. On closer investigation, commits f3ea3e3e8 et al were a few bricks shy of a load. What we need is not so much to lock down the result type of a FieldSelect, as to lock down the existence of the column it's trying to extract.

[COMMITTERS] pgsql: Rethink the dependencies recorded for FieldSelect/FieldStore nod

Rethink the dependencies recorded for FieldSelect/FieldStore nodes. On closer investigation, commits f3ea3e3e8 et al were a few bricks shy of a load. What we need is not so much to lock down the result type of a FieldSelect, as to lock down the existence of the column it's trying to extract.

[COMMITTERS] pgsql: Rethink the dependencies recorded for FieldSelect/FieldStore nod

Rethink the dependencies recorded for FieldSelect/FieldStore nodes. On closer investigation, commits f3ea3e3e8 et al were a few bricks shy of a load. What we need is not so much to lock down the result type of a FieldSelect, as to lock down the existence of the column it's trying to extract.

[COMMITTERS] pgsql: Rethink the dependencies recorded for FieldSelect/FieldStore nod

Rethink the dependencies recorded for FieldSelect/FieldStore nodes. On closer investigation, commits f3ea3e3e8 et al were a few bricks shy of a load. What we need is not so much to lock down the result type of a FieldSelect, as to lock down the existence of the column it's trying to extract.

[COMMITTERS] pgsql: Rethink the dependencies recorded for FieldSelect/FieldStore nod

Rethink the dependencies recorded for FieldSelect/FieldStore nodes. On closer investigation, commits f3ea3e3e8 et al were a few bricks shy of a load. What we need is not so much to lock down the result type of a FieldSelect, as to lock down the existence of the column it's trying to extract.

[COMMITTERS] pgsql: Rethink the dependencies recorded for FieldSelect/FieldStore nod

Rethink the dependencies recorded for FieldSelect/FieldStore nodes. On closer investigation, commits f3ea3e3e8 et al were a few bricks shy of a load. What we need is not so much to lock down the result type of a FieldSelect, as to lock down the existence of the column it's trying to extract.

[COMMITTERS] pgsql: Move new structure member to the end.

Move new structure member to the end. Reduces ABI breakage. Per Tom Lane. Discussion: http://postgr.es/m/4035.1509113...@sss.pgh.pa.us Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/69fc2ca4ccdc70c6f9bd7909a771b0983017cb5c Modified Files --

[COMMITTERS] pgsql: Revert "Move new structure member to the end."

Revert "Move new structure member to the end." This reverts commit 94d622f27be6d48e61a68496da4f2efb06fe8746. That commit was supposed to get pushed to REL_10_STABLE, but I messed up. Branch -- master Details ---

Re: [COMMITTERS] pgsql: Move new structure member to the end.

On Fri, Oct 27, 2017 at 4:48 PM, Tom Lane wrote: > Robert Haas writes: >> Move new structure member to the end. >> Reduces ABI breakage. Per Tom Lane. > >> Branch >> -- >> master > > Uh, no. I wasn't complaining that you made this change in master;

Re: [COMMITTERS] pgsql: Move new structure member to the end.

Robert Haas writes: > Move new structure member to the end. > Reduces ABI breakage. Per Tom Lane. > Branch > -- > master Uh, no. I wasn't complaining that you made this change in master; it's fine there. Where it's not fine is REL_10_STABLE.

[COMMITTERS] pgsql: Doc: mention that you can't PREPARE TRANSACTION after NOTIFY.

Doc: mention that you can't PREPARE TRANSACTION after NOTIFY. The NOTIFY page said this already, but the PREPARE TRANSACTION page missed it. Discussion: https://postgr.es/m/20171024010602.1488.80...@wrigleys.postgresql.org Branch -- REL9_2_STABLE Details ---

[COMMITTERS] pgsql: Doc: mention that you can't PREPARE TRANSACTION after NOTIFY.

Doc: mention that you can't PREPARE TRANSACTION after NOTIFY. The NOTIFY page said this already, but the PREPARE TRANSACTION page missed it. Discussion: https://postgr.es/m/20171024010602.1488.80...@wrigleys.postgresql.org Branch -- REL9_4_STABLE Details ---

[COMMITTERS] pgsql: Doc: mention that you can't PREPARE TRANSACTION after NOTIFY.

Doc: mention that you can't PREPARE TRANSACTION after NOTIFY. The NOTIFY page said this already, but the PREPARE TRANSACTION page missed it. Discussion: https://postgr.es/m/20171024010602.1488.80...@wrigleys.postgresql.org Branch -- REL9_5_STABLE Details ---

[COMMITTERS] pgsql: Doc: mention that you can't PREPARE TRANSACTION after NOTIFY.

Doc: mention that you can't PREPARE TRANSACTION after NOTIFY. The NOTIFY page said this already, but the PREPARE TRANSACTION page missed it. Discussion: https://postgr.es/m/20171024010602.1488.80...@wrigleys.postgresql.org Branch -- REL9_3_STABLE Details ---

[COMMITTERS] pgsql: Doc: mention that you can't PREPARE TRANSACTION after NOTIFY.

Doc: mention that you can't PREPARE TRANSACTION after NOTIFY. The NOTIFY page said this already, but the PREPARE TRANSACTION page missed it. Discussion: https://postgr.es/m/20171024010602.1488.80...@wrigleys.postgresql.org Branch -- REL_10_STABLE Details ---

[COMMITTERS] pgsql: Doc: mention that you can't PREPARE TRANSACTION after NOTIFY.

Doc: mention that you can't PREPARE TRANSACTION after NOTIFY. The NOTIFY page said this already, but the PREPARE TRANSACTION page missed it. Discussion: https://postgr.es/m/20171024010602.1488.80...@wrigleys.postgresql.org Branch -- REL9_6_STABLE Details ---

[COMMITTERS] pgsql: Doc: mention that you can't PREPARE TRANSACTION after NOTIFY.

Doc: mention that you can't PREPARE TRANSACTION after NOTIFY. The NOTIFY page said this already, but the PREPARE TRANSACTION page missed it. Discussion: https://postgr.es/m/20171024010602.1488.80...@wrigleys.postgresql.org Branch -- master Details ---

[COMMITTERS] pgsql: Move new structure member to the end.

Move new structure member to the end. Reduces ABI breakage. Per Tom Lane. Discussion: http://postgr.es/m/4035.1509113...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/94d622f27be6d48e61a68496da4f2efb06fe8746 Modified Files --

Re: [COMMITTERS] pgsql: Fix mistaken failure to allow parallelism in corner case.

Robert Haas writes: > Fix mistaken failure to allow parallelism in corner case. You can't insert fields into the middle of a widely-known struct in the back branches. In v10, this broke ABI compatibility for any extension touching estate->es_query_dsa, which seems unlikely

[COMMITTERS] pgsql: Fix mistaken failure to allow parallelism in corner case.

Fix mistaken failure to allow parallelism in corner case. If we try to run a parallel plan in serial mode because, for example, it's going to be scanned via a cursor, but for some reason we're already in parallel mode (for example because an outer query is running in parallel), we'd incorrectly

[COMMITTERS] pgsql: Fix mistaken failure to allow parallelism in corner case.

Fix mistaken failure to allow parallelism in corner case. If we try to run a parallel plan in serial mode because, for example, it's going to be scanned via a cursor, but for some reason we're already in parallel mode (for example because an outer query is running in parallel), we'd incorrectly

[COMMITTERS] pgsql: Fix mistaken failure to allow parallelism in corner case.

Fix mistaken failure to allow parallelism in corner case. If we try to run a parallel plan in serial mode because, for example, it's going to be scanned via a cursor, but for some reason we're already in parallel mode (for example because an outer query is running in parallel), we'd incorrectly