[COMMITTERS] pgsql: Disallow set-returning functions inside CASE or COALESCE.
Disallow set-returning functions inside CASE or COALESCE. When we reimplemented SRFs in commit 69f4b9c85, our initial choice was to allow the behavior to vary from historical practice in cases where a SRF call appeared within a conditional-execution construct (currently, only CASE or COALESCE). But that was controversial to begin with, and subsequent discussion has resulted in a consensus that it's better to throw an error instead of executing the query differently from before, so long as we can provide a reasonably clear error message and a way to rewrite the query. Hence, add a parser mechanism to allow detection of such cases during parse analysis. The mechanism just requires storing, in the ParseState, a pointer to the set-returning FuncExpr or OpExpr most recently emitted by parse analysis. Then the parsing functions for CASE and COALESCE can detect the presence of a SRF in their arguments by noting whether this pointer changes while analyzing their arguments. Furthermore, if it does, it provides a suitable error cursor location for the complaint. (This means that if there's more than one SRF in the arguments, the error will point at the last one to be analyzed not the first. While connoisseurs of parsing behavior might find that odd, it's unlikely the average user would ever notice.) While at it, we can also provide more specific error messages than before about some pre-existing restrictions, such as no-SRFs-within-aggregates. Also, reject at parse time cases where a NULLIF or IS DISTINCT FROM construct would need to return a set. We've never supported that, but the restriction is depended on in more subtle ways now, so it seems wise to detect it at the start. Also, provide some documentation about how to rewrite a SRF-within-CASE query using a custom wrapper SRF. It turns out that the information_schema.user_mapping_options view contained an instance of exactly the behavior we're now forbidding; but rewriting it makes it more clear and safer too. initdb forced because of user_mapping_options change. Patch by me, with error message suggestions from Alvaro Herrera and Andres Freund, pursuant to a complaint from Regina Obe. Discussion: https://postgr.es/m/01d2d5de$d8d66170$8a832450$@pcorp.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0436f6bde8848b7135f19dd7f8548b8c2ae89a34 Modified Files -- doc/src/sgml/xfunc.sgml| 83 +- src/backend/catalog/information_schema.sql | 8 +-- src/backend/executor/functions.c | 1 + src/backend/parser/parse_agg.c | 8 +++ src/backend/parser/parse_clause.c | 38 +++--- src/backend/parser/parse_expr.c| 79 +--- src/backend/parser/parse_func.c| 41 +-- src/backend/parser/parse_oper.c| 14 +++-- src/include/catalog/catversion.h | 2 +- src/include/parser/parse_func.h| 5 +- src/include/parser/parse_node.h| 5 ++ src/include/parser/parse_oper.h| 2 +- src/test/regress/expected/create_table.out | 2 +- src/test/regress/expected/rangefuncs.out | 12 - src/test/regress/expected/tsrf.out | 24 +++-- src/test/regress/sql/rangefuncs.sql| 9 src/test/regress/sql/tsrf.sql | 7 +++ 17 files changed, 249 insertions(+), 91 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: doc: Update example version numbers in pg_upgrade documentation
Thanks, it was kind of odd to mention unsupported versions in the examples, 8.4, 9.0. --- On Tue, Jun 13, 2017 at 08:11:54PM +, Peter Eisentraut wrote: > doc: Update example version numbers in pg_upgrade documentation > > The exact numbers don't matter, since they are examples, but it was > looking quite dated. > > For the target version, we now automatically substitute the current > major version. The updated example source version should be good for a > couple of years. > > Branch > -- > master > > Details > --- > https://git.postgresql.org/pg/commitdiff/39da0f709db4d9f16f46be56ae401df72aab93c0 > > Modified Files > -- > doc/src/sgml/ref/pgupgrade.sgml | 26 +- > 1 file changed, 13 insertions(+), 13 deletions(-) > > > -- > Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-committers -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: doc: Update example version numbers in pg_upgrade documentation
doc: Update example version numbers in pg_upgrade documentation The exact numbers don't matter, since they are examples, but it was looking quite dated. For the target version, we now automatically substitute the current major version. The updated example source version should be good for a couple of years. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/39da0f709db4d9f16f46be56ae401df72aab93c0 Modified Files -- doc/src/sgml/ref/pgupgrade.sgml | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Assert that we don't invent relfilenodes or type OIDs in binary
On Tue, Jun 13, 2017 at 03:10:16PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Tue, Jun 13, 2017 at 11:52:04AM -0700, Andres Freund wrote: > >> I'm not sure what you're actually concerned about here? > > > I am concerned a non-assert build will not error out, but if no one else > > is concerned about that, I am fine. > > I think in a production situation, we actually don't want it to error > out. The odds are fairly good that the run would complete successfully > (ie, the potential OID collision never actually materializes). So all > we're doing is converting a possible failure into an unavoidable one. > > Where we want to hear about the problem is in development. So really > an Assert is the right thing. OK, but my point is that all the other places, which seems similar, error out in production. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Assert that we don't invent relfilenodes or type OIDs in binary
Bruce Momjian writes: > On Tue, Jun 13, 2017 at 11:52:04AM -0700, Andres Freund wrote: >> I'm not sure what you're actually concerned about here? > I am concerned a non-assert build will not error out, but if no one else > is concerned about that, I am fine. I think in a production situation, we actually don't want it to error out. The odds are fairly good that the run would complete successfully (ie, the potential OID collision never actually materializes). So all we're doing is converting a possible failure into an unavoidable one. Where we want to hear about the problem is in development. So really an Assert is the right thing. regards, tom lane -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Assert that we don't invent relfilenodes or type OIDs in binary
On Tue, Jun 13, 2017 at 11:52:04AM -0700, Andres Freund wrote: > On 2017-06-13 13:45:12 -0400, Bruce Momjian wrote: > > On Tue, Jun 13, 2017 at 01:39:34PM -0400, Tom Lane wrote: > > > Bruce Momjian writes: > > > > Uh, is there a reason this is only an Assert(), meaning it only checks > > > > in assert builds. pg_upgrade already has a lot of checks and they are > > > > all fatal. > > > > > > Yeah, I didn't think it was worth adding overhead to production builds > > > for it. > > > > Uh, you realize there are already many pg_upgrade sanity checks in the > > backend that are not asserts, right? > > And? Not that it'll make a huge difference, but GetNewOidWithIndex() is > a relatively hot-path in some workloads (e.g. with lots of toasted > data), so it actually can make a difference. And for debugging asserts > are often actually more useful, because you get a backtrace. > > I'm not sure what you're actually concerned about here? I am concerned a non-assert build will not error out, but if no one else is concerned about that, I am fine. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Assert that we don't invent relfilenodes or type OIDs in binary
On 2017-06-13 13:45:12 -0400, Bruce Momjian wrote: > On Tue, Jun 13, 2017 at 01:39:34PM -0400, Tom Lane wrote: > > Bruce Momjian writes: > > > Uh, is there a reason this is only an Assert(), meaning it only checks > > > in assert builds. pg_upgrade already has a lot of checks and they are > > > all fatal. > > > > Yeah, I didn't think it was worth adding overhead to production builds > > for it. > > Uh, you realize there are already many pg_upgrade sanity checks in the > backend that are not asserts, right? And? Not that it'll make a huge difference, but GetNewOidWithIndex() is a relatively hot-path in some workloads (e.g. with lots of toasted data), so it actually can make a difference. And for debugging asserts are often actually more useful, because you get a backtrace. I'm not sure what you're actually concerned about here? - Andres -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: psql: Use more consistent capitalization of some output headings
psql: Use more consistent capitalization of some output headings Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/272171279f8676c57b3a8edf7daf792ad55b2c2c Modified Files -- .../hstore_plperl/expected/create_transform.out| 6 +- contrib/postgres_fdw/expected/postgres_fdw.out | 84 +-- src/bin/psql/describe.c| 20 +-- .../test_extensions/expected/test_extensions.out | 14 +- .../test_extensions/sql/test_extensions.sql| 4 +- src/test/regress/expected/foreign_data.out | 158 ++--- 6 files changed, 143 insertions(+), 143 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Assert that we don't invent relfilenodes or type OIDs in binary
On Tue, Jun 13, 2017 at 01:39:34PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > Uh, is there a reason this is only an Assert(), meaning it only checks > > in assert builds. pg_upgrade already has a lot of checks and they are > > all fatal. > > Yeah, I didn't think it was worth adding overhead to production builds > for it. Uh, you realize there are already many pg_upgrade sanity checks in the backend that are not asserts, right? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Assert that we don't invent relfilenodes or type OIDs in binary
Bruce Momjian writes: > Uh, is there a reason this is only an Assert(), meaning it only checks > in assert builds. pg_upgrade already has a lot of checks and they are > all fatal. Yeah, I didn't think it was worth adding overhead to production builds for it. regards, tom lane -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Assert that we don't invent relfilenodes or type OIDs in binary
Uh, is there a reason this is only an Assert(), meaning it only checks in assert builds. pg_upgrade already has a lot of checks and they are all fatal. --- On Tue, Jun 13, 2017 at 12:04:48AM +, Tom Lane wrote: > Assert that we don't invent relfilenodes or type OIDs in binary upgrade. > > During pg_upgrade's restore run, all relfilenode choices should be > overridden by commands in the dump script. If we ever find ourselves > choosing a relfilenode in the ordinary way, someone blew it. Likewise for > pg_type OIDs. Since pg_upgrade might well succeed anyway, if there happens > not to be a conflict during the regression test run, we need assertions > here to keep us on the straight and narrow. > > We might someday be able to remove the assertion in GetNewRelFileNode, > if pg_upgrade is rewritten to remove its assumption that old and new > relfilenodes always match. But it's hard to see how to get rid of the > pg_type OID constraint, since those OIDs are embedded in user tables > in some cases. > > Back-patch as far as 9.5, because of the risk of back-patches breaking > something here even if it works in HEAD. I'd prefer to go back further, > but 9.4 fails both assertions due to get_rel_infos()'s use of a temporary > table. We can't use the later-branch solution of a CTE for compatibility > reasons (cf commit 5d16332e9), and it doesn't seem worth inventing some > other way to do the query. (I did check, by dint of changing the Asserts > to elog(WARNING), that there are no other cases of unwanted OID assignments > during 9.4's regression test run.) > > Discussion: https://postgr.es/m/19785.1497215...@sss.pgh.pa.us > > Branch > -- > REL9_6_STABLE > > Details > --- > https://git.postgresql.org/pg/commitdiff/318fd99ce7e775158c87b8515780f2663d2df429 > > Modified Files > -- > src/backend/catalog/catalog.c | 16 > 1 file changed, 16 insertions(+) > > > -- > Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-committers -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Re-run pgindent.
Re-run pgindent. This is just to have a clean base state for testing of Piotr Stefaniak's latest version of FreeBSD indent. I fixed up a couple of places where pgindent would have changed format not-nicely. perltidy not included. Discussion: https://postgr.es/m/vi1pr03mb119959f4b65f000ca7cd9f6bf2...@vi1pr03mb1199.eurprd03.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/651902deb1551db8b401fdeab9bdb8a61cee7f9f Modified Files -- src/backend/access/brin/brin_pageops.c | 2 +- src/backend/access/brin/brin_validate.c | 4 +-- src/backend/access/gin/ginvalidate.c| 4 +-- src/backend/access/gist/gistvalidate.c | 4 +-- src/backend/catalog/index.c | 2 +- src/backend/commands/copy.c | 4 +-- src/backend/commands/vacuumlazy.c | 2 +- src/backend/commands/variable.c | 2 +- src/backend/executor/execMain.c | 6 ++-- src/backend/executor/nodeModifyTable.c | 4 +-- src/backend/libpq/auth-scram.c | 9 ++--- src/backend/replication/logical/relation.c | 2 +- src/backend/replication/logical/tablesync.c | 51 - src/backend/replication/logical/worker.c| 46 +- src/backend/rewrite/rewriteHandler.c| 2 +- src/backend/storage/page/bufpage.c | 4 +-- src/backend/tcop/postgres.c | 4 +-- src/backend/utils/adt/json.c| 4 +-- src/backend/utils/adt/jsonb.c | 6 ++-- src/bin/psql/describe.c | 2 +- src/include/storage/procsignal.h| 3 +- src/interfaces/ecpg/ecpglib/pg_type.h | 28 src/interfaces/libpq/fe-auth.c | 4 +-- src/interfaces/libpq/fe-connect.c | 13 ++-- 24 files changed, 113 insertions(+), 99 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Always initialize PartitionBoundInfoData's null_index.
Always initialize PartitionBoundInfoData's null_index. This doesn't actually matter at present, because the current code never consults null_index for range partitions. However, leaving it uninitialized is still a bad idea, so let's not do that. Amul Sul, reviewed by Ashutosh Bapat Discussion: http://postgr.es/m/CAAJ_b94AkEzcx+12ySCnbMDX7=udf4bjnobgfmqbb0rnsto...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/096f1ccd5290286b135822bb282fa884454d4b69 Modified Files -- src/backend/catalog/partition.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Teach relation_is_updatable() about partitioned tables.
Teach relation_is_updatable() about partitioned tables. Table partitioning, introduced in commit f0e44751d7, added a new relkind - RELKIND_PARTITIONED_TABLE. Update relation_is_updatable() to handle it. Specifically, partitioned tables and simple views built on top of them are updatable. This affects the SQL-callable functions pg_relation_is_updatable() and pg_column_is_updatable(), and the views information_schema.views and information_schema.columns. Dean Rasheed, reviewed by Ashutosh Bapat. Discussion: https://postgr.es/m/CAEZATCXnbiFkMXgF4Ez1pmM2c-tS1z33bSq7OGbw7QQhHov%2B6Q%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b6263cd851ef245a5dc38119448e029ca1592da4 Modified Files -- src/backend/rewrite/rewriteHandler.c | 6 +++-- src/test/regress/expected/updatable_views.out | 36 +++ src/test/regress/sql/updatable_views.sql | 10 3 files changed, 50 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: libpq: Message style improvements
libpq: Message style improvements Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2e3fc7a7d322289c70f89199be0a5e899ec7d9b9 Modified Files -- src/interfaces/libpq/fe-auth.c| 3 ++- src/interfaces/libpq/fe-connect.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix failure to remove dependencies when a partition is detached.
Fix failure to remove dependencies when a partition is detached. Otherwise, dropping the partitioned table will automatically drop any previously-detached children, which would be unfortunate. Ashutosh Bapat and Rahila Syed, reviewed by Amit Langote and by me. Discussion: http://postgr.es/m/cafjfprdowhugj45i25ilq4qitua0uh6rulx1h5ded4kbzj2...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ee252f074b88e34ff7ac2b45a73d3cee12b1c671 Modified Files -- src/backend/commands/tablecmds.c | 35 ++- src/test/regress/expected/alter_table.out | 13 src/test/regress/sql/alter_table.sql | 10 + 3 files changed, 44 insertions(+), 14 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: doc: Fix typo
doc: Fix typo Author: Julien Rouhaud Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/506b565831e6c88666c18a467377c2f98066ccac Modified Files -- doc/src/sgml/brin.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Fix collprovider of predefined collations
On 6/13/17 10:57, Tom Lane wrote: > I wrote: >> Peter Eisentraut writes: >>> Fix collprovider of predefined collations >>> An earlier version of the patch had collprovider as an integer and thus >>> set these to 0, but the correct setting is now null. > >> Surely this is not right. Neither collprovider nor the other fixed-length >> fields following it in pg_collation are marked nullable, and most of them >> are accessed as struct fields so that's not an easy thing to change. > > Ah, on looking closer, I see what the patch actually changes to null is > collversion not collprovider. So the patch is ok, the commit message > not so much. yup :( >> The fact that the buildfarm didn't blow up is a bit odd. Maybe we're >> missing some enforcement somewhere? > > As penance for the false alarm, I looked into that angle and indeed we > didn't have any cross-check against storing NULL from the BKI data into > a putatively not null column. We do now. great -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Fix collprovider of predefined collations
I wrote: > Peter Eisentraut writes: >> Fix collprovider of predefined collations >> An earlier version of the patch had collprovider as an integer and thus >> set these to 0, but the correct setting is now null. > Surely this is not right. Neither collprovider nor the other fixed-length > fields following it in pg_collation are marked nullable, and most of them > are accessed as struct fields so that's not an easy thing to change. Ah, on looking closer, I see what the patch actually changes to null is collversion not collprovider. So the patch is ok, the commit message not so much. > The fact that the buildfarm didn't blow up is a bit odd. Maybe we're > missing some enforcement somewhere? As penance for the false alarm, I looked into that angle and indeed we didn't have any cross-check against storing NULL from the BKI data into a putatively not null column. We do now. regards, tom lane -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: In initdb, defend against assignment of NULL values to not-null
In initdb, defend against assignment of NULL values to not-null columns. Previously, you could write _null_ in a BKI DATA line for a column that's supposed to be NOT NULL and initdb would let it pass, probably breaking subsequent accesses to the row. No doubt the original coding overlooked this simple sanity check because in the beginning we didn't have any way to mark catalog columns NOT NULL at initdb time. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b74701043e396a93f1f18098044741daaf75f761 Modified Files -- src/backend/bootstrap/bootstrap.c | 5 + 1 file changed, 5 insertions(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix typo
Fix typo Author: Masahiko Sawada Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f2a886104a6683227bfcb0932dde97d30b123961 Modified Files -- src/backend/storage/ipc/shm_mq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve code comments
Improve code comments Author: Erik Rijkers Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/88c6cff8e71eccac00fe68f4c15530161b99e6c5 Modified Files -- src/backend/replication/logical/tablesync.c | 46 ++--- 1 file changed, 23 insertions(+), 23 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Fix collprovider of predefined collations
Peter Eisentraut writes: > Fix collprovider of predefined collations > An earlier version of the patch had collprovider as an integer and thus > set these to 0, but the correct setting is now null. Surely this is not right. Neither collprovider nor the other fixed-length fields following it in pg_collation are marked nullable, and most of them are accessed as struct fields so that's not an easy thing to change. The fact that the buildfarm didn't blow up is a bit odd. Maybe we're missing some enforcement somewhere? regards, tom lane -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use correct ICU path for Windows 32 vs. 64 bit
Use correct ICU path for Windows 32 vs. 64 bit Author: Ashutosh Sharma Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ae1aa28eb6a0adb1ae0b36eb25a7d0ee2ee3db0b Modified Files -- src/tools/msvc/Solution.pm | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix collprovider of predefined collations
Fix collprovider of predefined collations An earlier version of the patch had collprovider as an integer and thus set these to 0, but the correct setting is now null. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ec7129b7812ce276520f749d0946875663c34093 Modified Files -- src/include/catalog/catversion.h | 2 +- src/include/catalog/pg_collation.h | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dump: Allow dumping default collation
pg_dump: Allow dumping default collation This will not work on restore, but it will allow dumping out pg_catalog for research and documentation. Reported-by: Neil Anderson Bug: #14701 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4955109d2281eacec6af8aee203382ac3991f1cf Modified Files -- src/bin/pg_dump/pg_dump.c | 3 +++ 1 file changed, 3 insertions(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Prevent copying default collation
Prevent copying default collation This will not have the desired effect and might lead to crashes when the copied collation is used. Reported-by: Tom Lane Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/17082a88eadfca79b50c04c5a78a2c38ee4f5d9c Modified Files -- src/backend/commands/collationcmds.c | 12 1 file changed, 12 insertions(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
