{"push_id":2329667997,"size":5,"distinct_size":1,"ref":"refs/heads/commitfest/17/1263","head":"af78fdbf9a139084595da0295b9f4bb66e438cc8","before":"58dd4d6d9dfdd9213cb79131e6b63a968ff8501f","commits":[{"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/postgresql-cfbot/postgresql/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/postgresql-cfbot/postgresql/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/postgresql-cfbot/postgresql/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/postgresql-cfbot/postgresql/commits/f9263006d871d127794a402a7bef713fdd882156"},{"sha":"af78fdbf9a139084595da0295b9f4bb66e438cc8","author":{"name":"Commitfest Bot","email":"aab6a594935fe5db0d690bc154b19f642bfbe9d7@cputube.org"},"message":"[CF 17/1263] amcheck heap verification\n\nThis commit was automatically generated by cfbot at commitfest.cputube.org.\nIt is based on patches submitted to the PostgreSQL mailing lists and\nregistered in the PostgreSQL Commitfest application.\n\nThis branch will be overwritten each time a new patch version is posted to\nthe email thread or the master branch changes.\n\nCommitfest entry: https://commitfest.postgresql.org/17/1263\nPatch(es): https://www.postgresql.org/message-id/CAH2-WznhneJxZdkbGbqaxeb9i0HRMCiaBAL%3DxvE6wkCiVpHeGw%40mail.gmail.com\nAuthor(s): Peter Geoghegan","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/af78fdbf9a139084595da0295b9f4bb66e438cc8"}]}
{"actor":{"display_login":"postgresql-cfbot"}}