{"push_id":2337262616,"size":32,"distinct_size":32,"ref":"refs/heads/master","head":"49bff412edd9eb226e146f6e4db7b5a8e843bd1f","before":"fad15f4a547ad433a28c370bd071b08df9e65f10","commits":[{"sha":"65b1d767856d96c7d6f952f30890dd5b7d4b66bb","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix oversight in CALL argument handling, and do some minor cleanup.\n\nCALL statements cannot support sub-SELECTs in the arguments of the called\nprocedure, since they just use ExecEvalExpr to evaluate such arguments.\nTeach transformSubLink() to reject the case, as it already does for other\ncontexts in which subqueries are not supported.\n\nIn passing, s/EXPR_KIND_CALL/EXPR_KIND_CALL_ARGUMENT/ to make that enum\nsymbol line up more closely with the phrasing of the error messages it is\nassociated with.  And fix someone's weak grasp of English grammar in the\npreceding EXPR_KIND_PARTITION_EXPRESSION addition.  Also update an\nincorrect comment in resolve_unique_index_expr (possibly it was correct\nwhen written, but nowadays transformExpr definitely does reject SRFs here).\n\nPer report from Pavel Stehule --- but this resolves only one of the bugs\nhe mentions.\n\nDiscussion: https://postgr.es/m/CAFj8pRDxOwPPzpA8i+AQeDQFj7bhVw-dR2==rfWZ3zMGkm568Q@mail.gmail.com","distinct":true,"url":"https://api.github.com/repos/tvondra/postgres/commits/65b1d767856d96c7d6f952f30890dd5b7d4b66bb"},{"sha":"d02d4a6d4f27c223f48b03a5e651a22c8460b3c4","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Avoid premature free of pass-by-reference CALL arguments.\n\nPrematurely freeing the EState used to evaluate CALL arguments led, in some\ncases, to passing dangling pointers to the procedure.  This was masked in\ntrivial cases because the argument pointers would point to Const nodes in\nthe original expression tree, and in some other cases because the result\nvalue would end up in the standalone ExprContext rather than in memory\nbelonging to the EState --- but that wasn't exactly high quality\nprogramming either, because the standalone ExprContext was never\nexplicitly freed, breaking assorted API contracts.\n\nIn addition, using a separate EState for each argument was just silly.\n\nSo let's use just one EState, and one ExprContext, and make the latter\nbelong to the former rather than be standalone, and clean up the EState\n(and hence the ExprContext) post-call.\n\nWhile at it, improve the function's commentary a bit.\n\nDiscussion: https://postgr.es/m/29173.1518282748@sss.pgh.pa.us","distinct":true,"url":"https://api.github.com/repos/tvondra/postgres/commits/d02d4a6d4f27c223f48b03a5e651a22c8460b3c4"},{"sha":"5c9f2564fabbc770ead3bd92136fdafc43654f27","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix assorted errors in pg_dump's handling of extended statistics objects.\n\npg_dump supposed that a stats object necessarily shares the same schema\nas its underlying table, and that it doesn't have a separate owner.\nThese things may have been true during early development of the feature,\nbut they are not true as of v10 release.\n\nFailure to track the object's schema separately turns out to have only\nlimited consequences, because pg_get_statisticsobjdef() always schema-\nqualifies the target object name in the generated CREATE STATISTICS command\n(a decision out of step with the rest of ruleutils.c, but I digress).\nTherefore the restored object would be in the right schema, so that the\nonly problem is that the TOC entry would be mislabeled as to schema.  That\ncould lead to wrong decisions for schema-selective restores, for example.\n\nThe ownership issue is a bit more serious: not only was the TOC entry\npotentially mislabeled as to owner, but pg_dump didn't bother to issue an\nALTER OWNER command at all, so that after restore the stats object would\ncontinue to be owned by the restoring superuser.\n\nA final point is that decisions as to whether to dump a stats object or\nnot were driven by whether the underlying table was dumped or not.  While\nthat's not wrong on its face, it won't scale nicely to the planned future\nextension to cross-table statistics.  Moreover, that design decision comes\nout of the view of stats objects as being auxiliary to a particular table,\nlike a rule or trigger, which is exactly where the above problems came\nfrom.  Since we're now treating stats objects more like independent objects\nin their own right, they ought to behave like standalone objects for this\npurpose too.  So change to using the generic selectDumpableObject() logic\nfor them (which presently amounts to \"dump if containing schema is to be\ndumped\").\n\nAlong the way to fixing this, restructure so that getExtendedStatistics\ncollects the identity info (only) for all extended stats objects in one\nquery, and then for each object actually being dumped, we retrieve the\ndefinition in dumpStatisticsExt.  This is necessary to ensure that\nschema-qualification in the generated CREATE STATISTICS command happens\nwith respect to the search path that pg_dump will now be using at restore\ntime (ie, the schema the stats object is in, not that of the underlying\ntable).  It's probably also significantly faster in the typical scenario\nwhere only a minority of tables have extended stats.\n\nBack-patch to v10 where extended stats were introduced.\n\nDiscussion: https://postgr.es/m/18272.1518328606@sss.pgh.pa.us","distinct":true,"url":"https://api.github.com/repos/tvondra/postgres/commits/5c9f2564fabbc770ead3bd92136fdafc43654f27"},{"sha":"91389228a1007fa3845e29e17568e52ab1726d5d","author":{"name":"Bruce Momjian","email":"c14305a822a8e0093cd46d644546baf20ea0af1b@momjian.us"},"message":"psql:  give ^D hint for \\q in place where \\q is ignored\n\nAlso add comment on why exit/quit are not documented.\n\nDiscussion: https://postgr.es/m/20180202053928.GA13472@momjian.us","distinct":true,"url":"https://api.github.com/repos/tvondra/postgres/commits/91389228a1007fa3845e29e17568e52ab1726d5d"},{"sha":"80f021ef139affdb219ccef71fff283e8f91f112","author":{"name":"Alvaro Herrera","email":"7cf34a26c111482b1b00703daedc3ff840f1e2cf@alvh.no-ip.org"},"message":"Add missing article\n\nNoticed while reviewing nearby text","distinct":true,"url":"https://api.github.com/repos/tvondra/postgres/commits/80f021ef139affdb219ccef71fff283e8f91f112"},{"sha":"88ef48c1ccee6a2200e01318180cf521413b3012","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Fix parallel index builds for dynamic_shared_memory_type=none.\n\nThe previous code failed to realize that this setting effectively\ndisables parallelism, and would crash if it decided to attempt\nparallelism anyway.  Instead, treat it as a disabling condition.\n\nKyotaro Horiguchi, who also reported the issue. Reviewed by Michael\nPaquier and Peter Geoghegan.\n\nDiscussion: http://postgr.es/m/20180209.170635.256350357.horiguchi.kyotaro@lab.ntt.co.jp","distinct":true,"url":"https://api.github.com/repos/tvondra/postgres/commits/88ef48c1ccee6a2200e01318180cf521413b3012"},{"sha":"8237f27b504ff1d1e2da7ae4c81a7f72ea0e0e3e","author":{"name":"Alvaro Herrera","email":"7cf34a26c111482b1b00703daedc3ff840f1e2cf@alvh.no-ip.org"},"message":"get_relid_attribute_name is dead, long live get_attname\n\nThe modern way is to use a missing_ok argument instead of two separate\nalmost-identical routines, so do that.\n\nAuthor: Michaël Paquier\nReviewed-by: Álvaro Herrera\nDiscussion: https://postgr.es/m/20180201063212.GE6398@paquier.xyz","distinct":true,"url":"https://api.github.com/repos/tvondra/postgres/commits/8237f27b504ff1d1e2da7ae4c81a7f72ea0e0e3e"},{"sha":"ebdb42a0d6a61b93a5bb9f4204408edf5959332c","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Fix typo\n\nAuthor: Masahiko Sawada <sawada.mshk@gmail.com>","distinct":true,"url":"https://api.github.com/repos/tvondra/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":true,"url":"https://api.github.com/repos/tvondra/postgres/commits/b4e2ada347bd8ae941171bd0761462e5b11b765d"},{"sha":"a7b8f0661d9ca9656ba58546ed871b36dbf8504d","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Fix typo","distinct":true,"url":"https://api.github.com/repos/tvondra/postgres/commits/a7b8f0661d9ca9656ba58546ed871b36dbf8504d"},{"sha":"7cd56f218d0f8953999b944bc558cd6684b15cdc","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Add tests for pg_get_functiondef","distinct":true,"url":"https://api.github.com/repos/tvondra/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":true,"url":"https://api.github.com/repos/tvondra/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":true,"url":"https://api.github.com/repos/tvondra/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":true,"url":"https://api.github.com/repos/tvondra/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":true,"url":"https://api.github.com/repos/tvondra/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":true,"url":"https://api.github.com/repos/tvondra/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":true,"url":"https://api.github.com/repos/tvondra/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":true,"url":"https://api.github.com/repos/tvondra/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":true,"url":"https://api.github.com/repos/tvondra/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":true,"url":"https://api.github.com/repos/tvondra/postgres/commits/9a725f7b5cb7e8c8894ef121b49eff9c265245c8"}]}
{"actor":{"display_login":"tvondra"}}