{"push_id":2378779926,"size":147,"distinct_size":32,"ref":"refs/heads/objaddr_nulls","head":"9aa60a457f836987e8425a3fb2cdca9cb8f4eef3","before":"bb2da6d10650d7499acbe04e2719659da7b445af","commits":[{"sha":"ebdb42a0d6a61b93a5bb9f4204408edf5959332c","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Fix typo\n\nAuthor: Masahiko Sawada <sawada.mshk@gmail.com>","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/ebdb42a0d6a61b93a5bb9f4204408edf5959332c"},{"sha":"b4e2ada347bd8ae941171bd0761462e5b11b765d","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"In LDAP test, restart after pg_hba.conf changes\n\nInstead of issuing a reload after pg_hba.conf changes between test\ncases, run a full restart.  With a reload, an error in the new\npg_hba.conf is ignored and the tests will continue to run with the old\nsettings, invalidating the subsequent test cases.  With a restart, a\nfaulty pg_hba.conf will lead to the test being aborted, which is what\nwe'd rather want.","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/b4e2ada347bd8ae941171bd0761462e5b11b765d"},{"sha":"a7b8f0661d9ca9656ba58546ed871b36dbf8504d","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Fix typo","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/a7b8f0661d9ca9656ba58546ed871b36dbf8504d"},{"sha":"7cd56f218d0f8953999b944bc558cd6684b15cdc","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Add tests for pg_get_functiondef","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/7cd56f218d0f8953999b944bc558cd6684b15cdc"},{"sha":"7a32ac8a66903de8c352735f2a26f610f5e47090","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Add procedure support to pg_get_functiondef\n\nThis also makes procedures work in psql's \\ef and \\sf commands.\n\nReported-by: Pavel Stehule <pavel.stehule@gmail.com>","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/7a32ac8a66903de8c352735f2a26f610f5e47090"},{"sha":"2ac3e6acc228e4b99022019379c6d5c4b61b231c","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"doc: pg_function_is_visible also applies to aggregates and procedures","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/2ac3e6acc228e4b99022019379c6d5c4b61b231c"},{"sha":"4b93f57999a2ca9b9c9e573ea32ab1aeaa8bf496","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Make plpgsql use its DTYPE_REC code paths for composite-type variables.\n\nFormerly, DTYPE_REC was used only for variables declared as \"record\";\nvariables of named composite types used DTYPE_ROW, which is faster for\nsome purposes but much less flexible.  In particular, the ROW code paths\nare entirely incapable of dealing with DDL-caused changes to the number\nor data types of the columns of a row variable, once a particular plpgsql\nfunction has been parsed for the first time in a session.  And, since the\nstored representation of a ROW isn't a tuple, there wasn't any easy way\nto deal with variables of domain-over-composite types, since the domain\nconstraint checking code would expect the value to be checked to be a\ntuple.  A lesser, but still real, annoyance is that ROW format cannot\nrepresent a true NULL composite value, only a row of per-field NULL\nvalues, which is not exactly the same thing.\n\nHence, switch to using DTYPE_REC for all composite-typed variables,\nwhether \"record\", named composite type, or domain over named composite\ntype.  DTYPE_ROW remains but is used only for its native purpose, to\nrepresent a fixed-at-compile-time list of variables, for instance the\ntargets of an INTO clause.\n\nTo accomplish this without taking significant performance losses, introduce\ninfrastructure that allows storing composite-type variables as \"expanded\nobjects\", similar to the \"expanded array\" infrastructure introduced in\ncommit 1dc5ebc90.  A composite variable's value is thereby kept (most of\nthe time) in the form of separate Datums, so that field accesses and\nupdates are not much more expensive than they were in the ROW format.\nThis holds the line, more or less, on performance of variables of named\ncomposite types in field-access-intensive microbenchmarks, and makes\nvariables declared \"record\" perform much better than before in similar\ntests.  In addition, the logic involved with enforcing composite-domain\nconstraints against updates of individual fields is in the expanded\nrecord infrastructure not plpgsql proper, so that it might be reusable\nfor other purposes.\n\nIn further support of this, introduce a typcache feature for assigning a\nunique-within-process identifier to each distinct tuple descriptor of\ninterest; in particular, DDL alterations on composite types result in a new\nidentifier for that type.  This allows very cheap detection of the need to\nrefresh tupdesc-dependent data.  This improves on the \"tupDescSeqNo\" idea\nI had in commit 687f096ea: that assigned identifying sequence numbers to\nsuccessive versions of individual composite types, but the numbers were not\nunique across different types, nor was there support for assigning numbers\nto registered record types.\n\nIn passing, allow plpgsql functions to accept as well as return type\n\"record\".  There was no good reason for the old restriction, and it\nwas out of step with most of the other PLs.\n\nTom Lane, reviewed by Pavel Stehule\n\nDiscussion: https://postgr.es/m/8962.1514399547@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/4b93f57999a2ca9b9c9e573ea32ab1aeaa8bf496"},{"sha":"40301c1c8bcbe92a9ba9bf017da03e83476ae0e5","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Speed up plpgsql function startup by doing fewer pallocs.\n\nPreviously, copy_plpgsql_datum did a separate palloc for each variable\nneeding instance-local storage.  In simple benchmarks this made for a\nnoticeable fraction of the total runtime.  Improve it by precalculating\nthe space needed for all of a function's variables and doing just one\npalloc for all of them.\n\nIn passing, remove PLPGSQL_DTYPE_EXPR from the list of plpgsql \"datum\"\ntypes, since in fact it has nothing in common with the others, and there\nis noplace that needs to discriminate on the basis of dtype between an\nexpression and any type of datum.  And add comments clarifying which\ndatum struct fields are generic and which aren't.\n\nTom Lane, reviewed by Pavel Stehule\n\nDiscussion: https://postgr.es/m/11986.1514407114@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/40301c1c8bcbe92a9ba9bf017da03e83476ae0e5"},{"sha":"fd333bc763ea104f2a2c10c6b0061c996d4a2f5a","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Speed up plpgsql trigger startup by introducing \"promises\".\n\nOver the years we've accreted quite a few special variables that are\npredefined in plpgsql trigger functions.  The cost of initializing these\nvariables to their defined values turns out to be a significant part of\nthe runtime of simple triggers; but, undoubtedly, most real-world triggers\nnever examine the values of most of these variables.\n\nTo improve matters, invent the notion of a variable that has a \"promise\"\nattached to it, specifying which of the predetermined values should be\nassigned to the variable if anything ever reads it.  This eliminates all\nthe unneeded startup overhead, in return for a small penalty on accesses\nto these variables.\n\nTom Lane, reviewed by Pavel Stehule\n\nDiscussion: https://postgr.es/m/11986.1514407114@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/fd333bc763ea104f2a2c10c6b0061c996d4a2f5a"},{"sha":"f9263006d871d127794a402a7bef713fdd882156","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Support CONSTANT/NOT NULL/initial value for plpgsql composite variables.\n\nThese features were never implemented previously for composite or record\nvariables ... not that the documentation admitted it, so there's no doc\nupdates here.\n\nThis also fixes some issues concerning enforcing DOMAIN NOT NULL\nconstraints against plpgsql variables, although I'm not sure that\nthat topic is completely dealt with.\n\nI created a new plpgsql test file for these features, and moved the\none relevant existing test case into that file.\n\nTom Lane, reviewed by Daniel Gustafsson\n\nDiscussion: https://postgr.es/m/18362.1514605650@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/f9263006d871d127794a402a7bef713fdd882156"},{"sha":"e748e902def40ee52d1ef0b770fd24aa0835e304","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix broken logic for reporting PL/Python function names in errcontext.\n\nplpython_error_callback() reported the name of the function associated\nwith the topmost PL/Python execution context.  This was not merely\nwrong if there were nested PL/Python contexts, but it risked a core\ndump if the topmost one is an inline code block rather than a named\nfunction.  That will have proname = NULL, and so we were passing a NULL\npointer to snprintf(\"%s\").  It seems that none of the PL/Python-testing\nmachines in the buildfarm will dump core for that, but some platforms do,\nas reported by Marina Polyakova.\n\nInvestigation finds that there actually is an existing regression test\nthat used to prove that the behavior was wrong, though apparently no one\nhad noticed that it was printing the wrong function name.  It stopped\nshowing the problem in 9.6 when we adjusted psql to not print CONTEXT\nby default for NOTICE messages.  The problem is masked (if your platform\navoids the core dump) in error cases, because PL/Python will throw away\nthe originally generated error info in favor of a new traceback produced\nat the outer level.\n\nRepair by using ErrorContextCallback.arg to pass the correct context to\nthe error callback.  Add a regression test illustrating correct behavior.\n\nBack-patch to all supported branches, since they're all broken this way.\n\nDiscussion: https://postgr.es/m/156b989dbc6fe7c4d3223cf51da61195@postgrespro.ru","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/e748e902def40ee52d1ef0b770fd24aa0835e304"},{"sha":"0c62356cc8777961221a643fa77f62e1c7361085","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Add an assertion that we don't pass NULL to snprintf(\"%s\").\n\nPer commit e748e902d, we appear to have little or no coverage in the\nbuildfarm of machines that will dump core when asked to printf a\nnull string pointer.  Let's try to improve that situation by adding\nan assertion that will make src/port/snprintf.c behave that way.\nSince it's just an assertion, it won't break anything in production\nbuilds, but it will help developers find this type of oversight.\n\nNote that while our buildfarm coverage of machines that use that\nsnprintf implementation is pretty thin on the Unix side (apparently\namounting only to gaur/pademelon), all of the MSVC critters use it.\n\nDiscussion: https://postgr.es/m/156b989dbc6fe7c4d3223cf51da61195@postgrespro.ru","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/0c62356cc8777961221a643fa77f62e1c7361085"},{"sha":"9a725f7b5cb7e8c8894ef121b49eff9c265245c8","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Silence assorted \"variable may be used uninitialized\" warnings.\n\nAll of these are false positives, but in each case a fair amount of\nanalysis is needed to see that, and it's not too surprising that not all\ncompilers are smart enough.  (In particular, in the logtape.c case, a\ncompiler lacking the knowledge provided by the Assert would almost surely\ncomplain, so that this warning will be seen in any non-assert build.)\n\nSome of these are of long standing while others are pretty recent,\nbut it only seems worth fixing them in HEAD.\n\nJaime Casanova, tweaked a bit by me\n\nDiscussion: https://postgr.es/m/CAJGNTeMcYAMJdPAom52dppLMtF-UnEZi0dooj==75OEv1EoBZA@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/9a725f7b5cb7e8c8894ef121b49eff9c265245c8"},{"sha":"6d7dc5350042697bbb141a7362649db7fa67bd55","author":{"name":"Andres Freund","email":"c6cbfe878b4ee67646e7630734db67f536518d54@anarazel.de"},"message":"Return implementation defined value if pg_$op_s$bit_overflow overflows.\n\nSome older compilers otherwise sometimes complain about undefined\nvalues, even though the return value should not be used in the\noverflow case.  We assume that any decent compiler will optimize away\nthe unnecessary assignment in performance critical cases.\n\nWe do not want to restrain the returned value to a specific value,\ne.g. 0 or the wrapped-around value, because some fast ways to\nimplement overflow detecting math do not easily allow for\nthat (e.g. msvc intrinsics).  As the function documentation already\ndocuments the returned value in case of intrinsics to be\nimplementation defined, no documentation has to be updated.\n\nPer complaint from Tom Lane and his buildfarm member prairiedog.\n\nAuthor: Andres Freund\nDiscussion: https://postgr.es/m/18169.1513958454@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/6d7dc5350042697bbb141a7362649db7fa67bd55"},{"sha":"feb1cc5593a5188796c2f52241f407500209fff2","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Stabilize new plpgsql_record regression tests.\n\nThe buildfarm's CLOBBER_CACHE_ALWAYS animals aren't happy with some\nof the test cases added in commit 4b93f5799.  There are two different\nproblems:\n\n* In two places, a different CONTEXT stack is shown because the error\nis detected in a different place, due to recompiling an expression\nfrom scratch rather than re-using a previously cached plan for it.\nI fixed these via the expedient of hiding the CONTEXT stack altogether.\n\n* In one place, a test expected to fail (because a cached plan hadn't\nbeen updated) actually succeeds (because the forced recompile makes\nit good).  I couldn't think of a simple workaround for this, so I've\njust commented out that test step altogether.\n\nI have hopes of improving things enough that both of these kluges can\nbe reverted eventually.  The first one is the same kind of problem\npreviously discussed at\nhttps://postgr.es/m/31545.1512924904@sss.pgh.pa.us\nbut there was insufficient agreement about how to fix it, so we\njust hacked around the output instability (commit 9edc97b71).\nThe second issue should be fixed by allowing the plan to be rebuilt\nwhen a type conflict is detected.  But for today, let's just make the\nbuildfarm green again.","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/feb1cc5593a5188796c2f52241f407500209fff2"},{"sha":"cbadba8dd632fc0d4162f7d686fec631bce7dfd0","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Revert \"Stabilize output of new regression test case\".\n\nThis effectively reverts commit 9edc97b71 (although the test is now\nin a different place and has different contents).  We don't need that\nhack anymore, because since commit 4b93f5799, this test case no longer\nthrows an error and so there's no displayed CONTEXT that could vary\ndepending on CLOBBER_CACHE_ALWAYS.  The underlying unstable-output\nproblem isn't really gone, of course, but it no longer manifests here.","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/cbadba8dd632fc0d4162f7d686fec631bce7dfd0"},{"sha":"03c5a00ea3867f5736da6cedce73b1eea88a98af","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Move the extern declaration for ExceptionalCondition into c.h.\n\nThis is the logical conclusion of our decision to support Assert()\nin both frontend and backend code: it should be possible to use that\nafter including just c.h.  But as things were arranged before, if\nyou wanted to use Assert() in code that might be compiled for either\nenvironment, you had to include postgres.h for the backend case.\nLet's simplify that.\n\nPer buildfarm, some of whose members started throwing warnings after\ncommit 0c62356cc added an Assert in src/port/snprintf.c.\n\nIt's possible that some other src/port files that use the stanza\n\n#ifndef FRONTEND\n#include \"postgres.h\"\n#else\n#include \"postgres_fe.h\"\n#endif\n\ncould now be simplified to just say '#include \"c.h\"'.  I have not\ntested for that, though, and it'd be unlikely to apply for more\nthan a small number of them.","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/03c5a00ea3867f5736da6cedce73b1eea88a98af"},{"sha":"51940f97607b7cb4d03bdd99e43abb1a1c6a0c47","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Cast to void in StaticAssertExpr, not its callers.\n\nSeems a bit silly that many (in fact all, as of today) uses of\nStaticAssertExpr would need to cast it to void to avoid warnings from\npickier compilers.  Let's just do the cast right in the macro, instead.\n\nIn passing, change StaticAssertExpr to StaticAssertStmt in one\nplace where that seems more apropos.\n\nDiscussion: https://postgr.es/m/16161.1518715186@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/51940f97607b7cb4d03bdd99e43abb1a1c6a0c47"},{"sha":"439c7bc1a070d746fab69d8696fca78673e64ba9","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Doc: fix minor bug in CREATE TABLE example.\n\nOne example in create_table.sgml claimed to be showing table constraint\nsyntax, but it was really column constraint syntax due to the omission\nof a comma.  This is both wrong and confusing, so fix it in all\nsupported branches.\n\nPer report from neil@postgrescompare.com.\n\nDiscussion: https://postgr.es/m/151871659877.1393.2431103178451978795@wrigleys.postgresql.org","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/439c7bc1a070d746fab69d8696fca78673e64ba9"},{"sha":"51db0d18fbf58b0c2e5ebc2b5b2c48daf45c8d93","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix plpgsql to enforce domain checks when returning a NULL domain value.\n\nIf a plpgsql function is declared to return a domain type, and the domain's\nconstraints forbid a null value, it was nonetheless possible to return\nNULL, because we didn't bother to check the constraints for a null result.\nI'd noticed this while fooling with domains-over-composite, but had not\ngotten around to fixing it immediately.\n\nAdd a regression test script exercising this and various other domain\ncases, largely borrowed from the plpython_types test.\n\nAlthough this is clearly a bug fix, I'm not sure whether anyone would\nthank us for changing the behavior in stable branches, so I'm inclined\nnot to back-patch.","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/51db0d18fbf58b0c2e5ebc2b5b2c48daf45c8d93"}]}
{"actor":{"display_login":"michaelpq"}}