[COMMITTERS] pgsql: Handle empty or all-blank PAGER setting more sanely in psql.
Handle empty or all-blank PAGER setting more sanely in psql. If the PAGER environment variable is set but contains an empty string, psql would pass it to "sh" which would silently exit, causing whatever query output we were printing to vanish entirely. This is quite mystifying; it took a long time for us to figure out that this was the cause of Joseph Brenner's trouble report. Rather than allowing that to happen, we should treat this as another way to specify "no pager". (We could alternatively treat it as selecting the default pager, but it seems more likely that the former is what the user meant to achieve by setting PAGER this way.) Nonempty, but all-white-space, PAGER values have the same behavior, and it's pretty easy to test for that, so let's handle that case the same way. Most other cases of faulty PAGER values will result in the shell printing some kind of complaint to stderr, which should be enough to diagnose the problem, so we don't need to work harder than this. (Note that there's been an intentional decision not to be very chatty about apparent failure returns from the pager process, since that may happen if, eg, the user quits the pager with control-C or some such. I'd just as soon not start splitting hairs about which exit codes might merit making our own report.) libpq's old PQprint() function was already on board with ignoring empty PAGER values, but for consistency, make it ignore all-white-space values as well. It's been like this a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/caffgvxwloe2novhzyjmqk8-j6tmhz42g8f3x0sorm44+stu...@mail.gmail.com Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/ccb84dae13c9fcb0dec00ee337179e9f36700ba3 Modified Files -- doc/src/sgml/ref/psql-ref.sgml | 5 +++-- src/bin/psql/print.c| 6 ++ src/interfaces/libpq/fe-print.c | 3 ++- 3 files changed, 11 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Handle empty or all-blank PAGER setting more sanely in psql.
Handle empty or all-blank PAGER setting more sanely in psql. If the PAGER environment variable is set but contains an empty string, psql would pass it to "sh" which would silently exit, causing whatever query output we were printing to vanish entirely. This is quite mystifying; it took a long time for us to figure out that this was the cause of Joseph Brenner's trouble report. Rather than allowing that to happen, we should treat this as another way to specify "no pager". (We could alternatively treat it as selecting the default pager, but it seems more likely that the former is what the user meant to achieve by setting PAGER this way.) Nonempty, but all-white-space, PAGER values have the same behavior, and it's pretty easy to test for that, so let's handle that case the same way. Most other cases of faulty PAGER values will result in the shell printing some kind of complaint to stderr, which should be enough to diagnose the problem, so we don't need to work harder than this. (Note that there's been an intentional decision not to be very chatty about apparent failure returns from the pager process, since that may happen if, eg, the user quits the pager with control-C or some such. I'd just as soon not start splitting hairs about which exit codes might merit making our own report.) libpq's old PQprint() function was already on board with ignoring empty PAGER values, but for consistency, make it ignore all-white-space values as well. It's been like this a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/caffgvxwloe2novhzyjmqk8-j6tmhz42g8f3x0sorm44+stu...@mail.gmail.com Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/82eb5c5144732df7774fe1f83c0b079e068c5be9 Modified Files -- doc/src/sgml/ref/psql-ref.sgml | 5 +++-- src/bin/psql/print.c| 6 ++ src/interfaces/libpq/fe-print.c | 3 ++- 3 files changed, 11 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Handle empty or all-blank PAGER setting more sanely in psql.
Handle empty or all-blank PAGER setting more sanely in psql. If the PAGER environment variable is set but contains an empty string, psql would pass it to "sh" which would silently exit, causing whatever query output we were printing to vanish entirely. This is quite mystifying; it took a long time for us to figure out that this was the cause of Joseph Brenner's trouble report. Rather than allowing that to happen, we should treat this as another way to specify "no pager". (We could alternatively treat it as selecting the default pager, but it seems more likely that the former is what the user meant to achieve by setting PAGER this way.) Nonempty, but all-white-space, PAGER values have the same behavior, and it's pretty easy to test for that, so let's handle that case the same way. Most other cases of faulty PAGER values will result in the shell printing some kind of complaint to stderr, which should be enough to diagnose the problem, so we don't need to work harder than this. (Note that there's been an intentional decision not to be very chatty about apparent failure returns from the pager process, since that may happen if, eg, the user quits the pager with control-C or some such. I'd just as soon not start splitting hairs about which exit codes might merit making our own report.) libpq's old PQprint() function was already on board with ignoring empty PAGER values, but for consistency, make it ignore all-white-space values as well. It's been like this a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/caffgvxwloe2novhzyjmqk8-j6tmhz42g8f3x0sorm44+stu...@mail.gmail.com Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/370c7a863aa7410029d1406a43871722b1f9a8af Modified Files -- doc/src/sgml/ref/psql-ref.sgml | 5 +++-- src/bin/psql/print.c| 6 ++ src/interfaces/libpq/fe-print.c | 3 ++- 3 files changed, 11 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Handle empty or all-blank PAGER setting more sanely in psql.
Handle empty or all-blank PAGER setting more sanely in psql. If the PAGER environment variable is set but contains an empty string, psql would pass it to "sh" which would silently exit, causing whatever query output we were printing to vanish entirely. This is quite mystifying; it took a long time for us to figure out that this was the cause of Joseph Brenner's trouble report. Rather than allowing that to happen, we should treat this as another way to specify "no pager". (We could alternatively treat it as selecting the default pager, but it seems more likely that the former is what the user meant to achieve by setting PAGER this way.) Nonempty, but all-white-space, PAGER values have the same behavior, and it's pretty easy to test for that, so let's handle that case the same way. Most other cases of faulty PAGER values will result in the shell printing some kind of complaint to stderr, which should be enough to diagnose the problem, so we don't need to work harder than this. (Note that there's been an intentional decision not to be very chatty about apparent failure returns from the pager process, since that may happen if, eg, the user quits the pager with control-C or some such. I'd just as soon not start splitting hairs about which exit codes might merit making our own report.) libpq's old PQprint() function was already on board with ignoring empty PAGER values, but for consistency, make it ignore all-white-space values as well. It's been like this a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/caffgvxwloe2novhzyjmqk8-j6tmhz42g8f3x0sorm44+stu...@mail.gmail.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/18f8f784cbbf96ef77eb8943b466b26605824c14 Modified Files -- doc/src/sgml/ref/psql-ref.sgml | 5 +++-- src/fe_utils/print.c| 6 ++ src/interfaces/libpq/fe-print.c | 3 ++- 3 files changed, 11 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Handle empty or all-blank PAGER setting more sanely in psql.
Handle empty or all-blank PAGER setting more sanely in psql. If the PAGER environment variable is set but contains an empty string, psql would pass it to "sh" which would silently exit, causing whatever query output we were printing to vanish entirely. This is quite mystifying; it took a long time for us to figure out that this was the cause of Joseph Brenner's trouble report. Rather than allowing that to happen, we should treat this as another way to specify "no pager". (We could alternatively treat it as selecting the default pager, but it seems more likely that the former is what the user meant to achieve by setting PAGER this way.) Nonempty, but all-white-space, PAGER values have the same behavior, and it's pretty easy to test for that, so let's handle that case the same way. Most other cases of faulty PAGER values will result in the shell printing some kind of complaint to stderr, which should be enough to diagnose the problem, so we don't need to work harder than this. (Note that there's been an intentional decision not to be very chatty about apparent failure returns from the pager process, since that may happen if, eg, the user quits the pager with control-C or some such. I'd just as soon not start splitting hairs about which exit codes might merit making our own report.) libpq's old PQprint() function was already on board with ignoring empty PAGER values, but for consistency, make it ignore all-white-space values as well. It's been like this a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/caffgvxwloe2novhzyjmqk8-j6tmhz42g8f3x0sorm44+stu...@mail.gmail.com Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/bb39f58f76b43bf0ef234e1baaf824e2cb9c9210 Modified Files -- doc/src/sgml/ref/psql-ref.sgml | 5 +++-- src/fe_utils/print.c| 6 ++ src/interfaces/libpq/fe-print.c | 3 ++- 3 files changed, 11 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Handle empty or all-blank PAGER setting more sanely in psql.
Handle empty or all-blank PAGER setting more sanely in psql. If the PAGER environment variable is set but contains an empty string, psql would pass it to "sh" which would silently exit, causing whatever query output we were printing to vanish entirely. This is quite mystifying; it took a long time for us to figure out that this was the cause of Joseph Brenner's trouble report. Rather than allowing that to happen, we should treat this as another way to specify "no pager". (We could alternatively treat it as selecting the default pager, but it seems more likely that the former is what the user meant to achieve by setting PAGER this way.) Nonempty, but all-white-space, PAGER values have the same behavior, and it's pretty easy to test for that, so let's handle that case the same way. Most other cases of faulty PAGER values will result in the shell printing some kind of complaint to stderr, which should be enough to diagnose the problem, so we don't need to work harder than this. (Note that there's been an intentional decision not to be very chatty about apparent failure returns from the pager process, since that may happen if, eg, the user quits the pager with control-C or some such. I'd just as soon not start splitting hairs about which exit codes might merit making our own report.) libpq's old PQprint() function was already on board with ignoring empty PAGER values, but for consistency, make it ignore all-white-space values as well. It's been like this a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/caffgvxwloe2novhzyjmqk8-j6tmhz42g8f3x0sorm44+stu...@mail.gmail.com Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/1ec5cc025b419f78bf1b16c7e857e9849cde2425 Modified Files -- doc/src/sgml/ref/psql-ref.sgml | 5 +++-- src/bin/psql/print.c| 6 ++ src/interfaces/libpq/fe-print.c | 3 ++- 3 files changed, 11 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Restore psql's SIGPIPE setting if popen() fails.
Restore psql's SIGPIPE setting if popen() fails. Ancient oversight in PageOutput(): if popen() fails, we'd better reset the SIGPIPE handler before returning stdout, because ClosePager() won't. Noticed while fixing the empty-PAGER issue. Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/311bc147ff0924b651f36910925a163c4f3b4a6c Modified Files -- src/bin/psql/print.c | 4 1 file changed, 4 insertions(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Restore psql's SIGPIPE setting if popen() fails.
Restore psql's SIGPIPE setting if popen() fails. Ancient oversight in PageOutput(): if popen() fails, we'd better reset the SIGPIPE handler before returning stdout, because ClosePager() won't. Noticed while fixing the empty-PAGER issue. Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/433e65c2bd907723a5d93b3f2ff0bdbc77a0b625 Modified Files -- src/bin/psql/print.c | 4 1 file changed, 4 insertions(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Restore psql's SIGPIPE setting if popen() fails.
Restore psql's SIGPIPE setting if popen() fails. Ancient oversight in PageOutput(): if popen() fails, we'd better reset the SIGPIPE handler before returning stdout, because ClosePager() won't. Noticed while fixing the empty-PAGER issue. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/29babe981cba76d934aa4936ca393ddd2894c4e7 Modified Files -- src/fe_utils/print.c | 2 ++ 1 file changed, 2 insertions(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Restore psql's SIGPIPE setting if popen() fails.
Restore psql's SIGPIPE setting if popen() fails. Ancient oversight in PageOutput(): if popen() fails, we'd better reset the SIGPIPE handler before returning stdout, because ClosePager() won't. Noticed while fixing the empty-PAGER issue. Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/93c78ba19b378b4b54dad5ceb4fdf063bb0998e1 Modified Files -- src/bin/psql/print.c | 2 ++ 1 file changed, 2 insertions(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Restore psql's SIGPIPE setting if popen() fails.
Restore psql's SIGPIPE setting if popen() fails. Ancient oversight in PageOutput(): if popen() fails, we'd better reset the SIGPIPE handler before returning stdout, because ClosePager() won't. Noticed while fixing the empty-PAGER issue. Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/cf59a8a4fe8dd83a069737ff32f1f211f352036c Modified Files -- src/bin/psql/print.c | 4 1 file changed, 4 insertions(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Restore psql's SIGPIPE setting if popen() fails.
Restore psql's SIGPIPE setting if popen() fails. Ancient oversight in PageOutput(): if popen() fails, we'd better reset the SIGPIPE handler before returning stdout, because ClosePager() won't. Noticed while fixing the empty-PAGER issue. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/b7e1ae2328f7d5a88d8916d78b4561d8ef16f99b Modified Files -- src/fe_utils/print.c | 2 ++ 1 file changed, 2 insertions(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Implement table partitioning.
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 Modified Files -- doc/src/sgml/catalogs.sgml | 129 +- doc/src/sgml/ref/alter_table.sgml | 117 +- doc/src/sgml/ref/create_foreign_table.sgml | 26 + doc/src/sgml/ref/create_table.sgml | 154 +++ src/backend/access/common/reloptions.c |2 + src/backend/catalog/Makefile |4 +- src/backend/catalog/aclchk.c |2 + src/backend/catalog/dependency.c | 10 +- src/backend/catalog/heap.c | 270 +++- src/backend/catalog/index.c|4 +- src/backend/catalog/objectaddress.c|5 +- src/backend/catalog/partition.c| 1917 src/backend/catalog/pg_constraint.c|2 +- src/backend/commands/analyze.c |6 +- src/backend/commands/copy.c| 174 ++- src/backend/commands/createas.c|2 +- src/backend/commands/indexcmds.c | 24 +- src/backend/commands/lockcmds.c|2 +- src/backend/commands/policy.c |5 +- src/backend/commands/seclabel.c|3 +- src/backend/commands/sequence.c|5 +- src/backend/commands/tablecmds.c | 1567 +-- src/backend/commands/trigger.c | 16 +- src/backend/commands/typecmds.c|3 +- src/backend/commands/vacuum.c |3 +- src/backend/commands/view.c|3 +- src/backend/executor/execMain.c| 125 +- src/backend/executor/nodeModifyTable.c | 154 ++- src/backend/nodes/copyfuncs.c | 81 ++ src/backend/nodes/equalfuncs.c | 70 + src/backend/nodes/nodeFuncs.c |6 + src/backend/nodes/outfuncs.c | 55 + src/backend/nodes/readfuncs.c | 34 + src/backend/optimizer/util/plancat.c | 20 + src/backend/parser/analyze.c |8 + src/backend/parser/gram.y | 347 - src/backend/parser/parse_agg.c | 10 + src/backend/parser/parse_expr.c|5 + src/backend/parser/parse_func.c|3 + src/backend/parser/parse_utilcmd.c | 326 - src/backend/rewrite/rewriteDefine.c|3 +- src/backend/rewrite/rewriteHandler.c |3 +- src/backend/rewrite/rowsecurity.c |3 +- src/backend/tcop/utility.c |6 +- src/backend/utils/adt/ruleutils.c | 241 src/backend/utils/cache/relcache.c | 364 +- src/backend/utils/cache/syscache.c | 12 + src/bin/pg_dump/common.c | 90 ++ src/bin/pg_dump/pg_dump.c | 186 ++- src/bin/pg_dump/pg_dump.h | 14 + src/bin/psql/describe.c| 146 ++- src/bin/psql/tab-complete.c|6 +- src/include/catalog/catversion.h |2 +- src/include/catalog/dependency.h |3 +- src/include/catalog/heap.h | 11 + src/include/catalog/indexing.h |3 + src/include/cat
[COMMITTERS] pgsql: Replace references to COLLATE "en_US" with COLLATE "C".
Replace references to COLLATE "en_US" with COLLATE "C". Commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 is turning the buildfarm red; let's try something hopefully more portable. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/71efd34fb8047e3e4fdfc9d6900b7affd20a0235 Modified Files -- src/test/regress/expected/alter_table.out | 6 +++--- src/test/regress/expected/create_table.out | 4 ++-- src/test/regress/sql/alter_table.sql | 6 +++--- src/test/regress/sql/create_table.sql | 2 +- 4 files changed, 9 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Replace references to COLLATE "en_CA" with COLLATE "POSIX".
Replace references to COLLATE "en_CA" with COLLATE "POSIX". Another attmempt to fix the tests which were added by commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/cd5d3af44e2a4f73c692d4653941c0516f967cb7 Modified Files -- src/test/regress/expected/alter_table.out | 2 +- src/test/regress/sql/alter_table.sql | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
