Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w5Qjo-003FBJ-1q for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Mar 2026 16:05:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w5Qjn-00EyB6-05 for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Mar 2026 16:05:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w5Qjm-00EyAf-0t for pgsql-hackers@lists.postgresql.org; Wed, 25 Mar 2026 16:05:43 +0000 Received: from fout-a2-smtp.messagingengine.com ([103.168.172.145]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w5Qjj-000000015uM-1VVK for pgsql-hackers@lists.postgresql.org; Wed, 25 Mar 2026 16:05:42 +0000 Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfout.phl.internal (Postfix) with ESMTP id 7C294EC00F8; Wed, 25 Mar 2026 12:05:38 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Wed, 25 Mar 2026 12:05:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eisentraut.org; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1774454738; x= 1774541138; bh=BAX8TXTwPfak95UHnjm0aZAEv7KCggZO29ADcTKZPrE=; b=W D0atxSgAdgjBJRSXrDLAQ+nH4dkIrouMv7bbqqHnqmTyleLT0CMKHQbawRy2xSS9 B8iiLUykCTRFDIxlppggK75Pc8nSkRIw8ajCz9E+VB3+Cx6oXVvxg6X16O9lnX8s X2cJeSeRjokJLWtf0yvWCTTPmRrL/NeX6RmQNnoE3Cl+SVupKizGNF5/tMOdmm5g bKiUGTtSt6Nu/W4H8jFRaAgWzw7Q9fAAxPSlRTTRse/JEUzCgimF0b1aIpxG83Z+ +NL+mFr5IxO+8KUYQ/uFvvoZByyXUqKOtovXZhCNF1X3ni2U5Xd+KkZ4CvISAACu Bt2dXPj5suzI0uLSHVotw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1774454738; x=1774541138; bh=BAX8TXTwPfak95UHnjm0aZAEv7KCggZO29A DcTKZPrE=; b=WzvAGVfq4/D9j3DnhDIC286vBwms9OlgtfA5wNPdPMaNWANVah4 hiEiq1xYxs6NoZxSoPXQeR3KWUZxM0utrZ4i8ki6jBPJH1gCWY1JTD6dVKP8Oh4L klKK281EugWKfTjDz9+HPnNLZjzlljrNhMlCiW1qMi4odIoQGRHlMu18DMtm4Ml3 2Hzwo/XiToFzCkNvS+Zx0VRjw5+ItZgyrBoVxbV7/grc/FIL1/oeZ0jM6jVeomUf c2xSteopmIcaQ7Dlj9jraALwZnqzx0cj6D6XSi9sEdtjFc2aXjNEnxhq3NuJo/RX uRjO2MqT43zQUTSueC+fXIyHGz4eFz0tvRw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdefvdegkeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurheptgfkffggfgfuvfevfhfhjgesmhdtreertddvjeenucfhrhhomheprfgvthgvrhcu gfhishgvnhhtrhgruhhtuceophgvthgvrhesvghishgvnhhtrhgruhhtrdhorhhgqeenuc ggtffrrghtthgvrhhnpeektdeutdfhvdfhveeigfffteegvdejvdfhhfevfeevgfdtgfel geehieevhffgieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehpvghtvghrsegvihhsvghnthhrrghuthdrohhrghdpnhgspghrtghpthhtohep fedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepphhjsehilhhluhhmihhnrghtvg gutghomhhpuhhtihhnghdrtghomhdprhgtphhtthhopehlihdrvghvrghnrdgthhgrohes ghhmrghilhdrtghomhdprhgtphhtthhopehpghhsqhhlqdhhrggtkhgvrhhssehlihhsth hsrdhpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: ie0a040ee:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 25 Mar 2026 12:05:37 -0400 (EDT) Content-Type: multipart/mixed; boundary="------------mEKjZoTVh3EJhp3MeaaSKxBS" Message-ID: Date: Wed, 25 Mar 2026 17:05:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: SQL:2011 Application Time Update & Delete To: Paul A Jungwirth Cc: Chao Li , PostgreSQL Hackers References: <53a13f97-340f-4d04-9dcc-77ca3ffb6a6a@eisentraut.org> <85ac7f0e-d95f-4377-ade0-8941fd328012@eisentraut.org> <7d63ddfa-c735-4dfe-8c7a-4f1e2a621058@eisentraut.org> <4606deaa-7d65-4f22-8a78-356c3180be9d@eisentraut.org> <53f1c094-3c29-4ef6-a9bd-dc2e7894ceb0@eisentraut.org> Content-Language: en-US From: Peter Eisentraut In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------mEKjZoTVh3EJhp3MeaaSKxBS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 13.03.26 18:06, Paul A Jungwirth wrote: >> 3.7) >> >> +-- UPDATE ... RETURNING returns only the updated values (not the >> inserted side values) >> >> This test looks redundant with earlier tests. Otherwise, maybe add a >> comment about how it's different. > > I don't think a top-level RETURNING test is redundant with the CTE > test. I expanded the comment here a bit to clarify the goal. It > addresses your question above: Should RETURNING include the inserted > leftovers? I don't think that makes sense: > > 1. Our docs say, "The optional RETURNING clause causes UPDATE to > compute and return value(s) based on each row actually updated." The > leftovers were not updated. > > 2. Conceptually, the leftovers represent what *didn't* change. > > 3. If you implemented this with a trigger, you also wouldn't get the > inserted leftovers. > > 4. The SQL standard doesn't have RETURNING. But it does say that to > insert the leftovers the system should execute a separate insert > "statement". So we should do something very similar to the trigger > case. UPDATE ... RETURNING is in my mind equivalent to the SQL standard SELECT ... FROM NEW TABLE (UPDATE ...) (see ). So I was hoping for an answer there, but it just says: "If TP simply contains a DCDT, then let S be the simply contained in TP. S shall not contain FOR PORTION OF." So we can pick our own behavior. Your explanation makes sense. (I suppose an alternative is that we also don't allow using FOR PORTION OF together with RETURNING?) >> 5) NULL bounds >> >> A general comment: In particular after studying these tests in detail, >> I'm suspicious that it's a good idea to interpret null bounds as >> unbounded. Expressions could return null for nested reasons, it would >> be very hard to follow that. Null values should mean "unknown", >> unbounded should be explicit. We have the keyword UNBOUNDED already, >> maybe you could use that? Or do you want to be able to return >> unboundedness from an expression? > > I like the idea of a keyword. I tried adding UNBOUNDED but it caused a > few hundred S/R and R/R conflicts that I couldn't easily resolve. A > year or two ago I had keywords here (MINVALUE/MAXVALUE IIRC), but it > required some nasty parser hacks. This is a pretty delicate area of > the grammar, because we have a_expr with FROM and TO and no > punctuation. I'm already doing some contortions to handle `FOR PORTION > OF valid_at FROM t1 + INTERVAL '1' YEAR TO MONTH TO t2`. > > A keyword is not offered by the standard here, so it would just be > custom syntactic sugar. No other RDBMS has one (I think). > > I think NULL is the right choice for unbounded. It is what range types > use, and we want this to mesh well with them. More important it works > for *any type*. We don't always have +/-Infinity. > > Also I think we should expand user choice rather than restrict it. If > users want to forbid nulls, they can (e.g. by using a domain type). > But if we forbid it, there is no way to override that decision. > > Going back to the UNBOUNDED keyword: if we forbid nulls, then a > keyword doesn't really add clarity, since users would already say > `-Infinity` or `Infinity`. It's really just a way to express what null > means in this context. Assuming we keep nulls, I'd like to keep > working on a keyword. But I think we could add it later. Yeah, this seems like something we could change later with relative ease. Maybe solicit some input from the public during beta? > Btw what do you think of the READ COMMITTED issues I brought up in my > third patch? We follow MariaDB here, but not DB2. DB2's behavior is > less problematic for users, although their isolation levels don't > quite match ours. If we're not okay with those results, we should > address them before merging the main patch. It's still hard to understand. I would be ok in general to say that results might be unexpected unless you use REPEATABLE READ. Especially as it seems that a technical solution to improve this would be possible later. But we should document this in more detail. The verbal explanations are hard to interpret. Could you maybe come up with a couple of ASCII-art flow charts that explains how things could go strange that we could put into the documentation? Could we actually put some of these strange/unexpected behaviors into the isolation tests? Right now we only test that the workaround works but not the initial problem. Is this possible? (Would we need injection points?) Could we cut back the isolation tests a bit? They are the second slowest isolation test now, and the second largest expected file. Maybe we don't need to test SERIALIZE separately? (Assume that SERIALIZE is as good as or better than REPEATABLE READ?) Attached is a patch with a few small cosmetic corrections. In ExecForPortionOfLeftovers(), the comment and code that I delete is duplicated before and inside the loop. The one before the loop is probably sufficient. Other than all that, this patch set (0001 through 0003) seems good to me. --------------mEKjZoTVh3EJhp3MeaaSKxBS Content-Type: text/plain; charset=UTF-8; name="nocfbot-0001-Fixups.patch" Content-Disposition: attachment; filename="nocfbot-0001-Fixups.patch" Content-Transfer-Encoding: base64 RnJvbSBlYjczZTE5NzFkMGZkMDViNmQ2NmMzYjc5NTUyYjM5NmZjNWYzYjIyIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQZXRlciBFaXNlbnRyYXV0IDxwZXRlckBlaXNlbnRy YXV0Lm9yZz4KRGF0ZTogV2VkLCAyNSBNYXIgMjAyNiAxNjo0MjoxOCArMDEwMApTdWJqZWN0 OiBbUEFUQ0hdIEZpeHVwcwoKLS0tCiBzcmMvYmFja2VuZC9leGVjdXRvci9ub2RlTW9kaWZ5 VGFibGUuYyAgICAgICB8ICA5ICstLS0tLS0tLQogc3JjL2JhY2tlbmQvcGFyc2VyL2FuYWx5 emUuYyAgICAgICAgICAgICAgICAgfCAgMyArLS0KIHNyYy9pbmNsdWRlL25vZGVzL2V4ZWNu b2Rlcy5oICAgICAgICAgICAgICAgIHwgIDEgKwogc3JjL3Rlc3QvcmVncmVzcy9leHBlY3Rl ZC9mb3JfcG9ydGlvbl9vZi5vdXQgfCAxOCArKysrKysrKystLS0tLS0tLS0KIHNyYy90ZXN0 L3JlZ3Jlc3Mvc3FsL2Zvcl9wb3J0aW9uX29mLnNxbCAgICAgIHwgMTggKysrKysrKysrLS0t LS0tLS0tCiA1IGZpbGVzIGNoYW5nZWQsIDIxIGluc2VydGlvbnMoKyksIDI4IGRlbGV0aW9u cygtKQoKZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2V4ZWN1dG9yL25vZGVNb2RpZnlUYWJs ZS5jIGIvc3JjL2JhY2tlbmQvZXhlY3V0b3Ivbm9kZU1vZGlmeVRhYmxlLmMKaW5kZXggZTE2 Mjk5Y2MyZWQuLjkzMjRiYjFhMDkzIDEwMDY0NAotLS0gYS9zcmMvYmFja2VuZC9leGVjdXRv ci9ub2RlTW9kaWZ5VGFibGUuYworKysgYi9zcmMvYmFja2VuZC9leGVjdXRvci9ub2RlTW9k aWZ5VGFibGUuYwpAQCAtMTM1LDYgKzEzNSw3IEBAIHR5cGVkZWYgc3RydWN0IFVwZGF0ZUNv bnRleHQKIAlMb2NrVHVwbGVNb2RlIGxvY2ttb2RlOwogfSBVcGRhdGVDb250ZXh0OwogCisK IHN0YXRpYyB2b2lkIEV4ZWNCYXRjaEluc2VydChNb2RpZnlUYWJsZVN0YXRlICptdHN0YXRl LAogCQkJCQkJCVJlc3VsdFJlbEluZm8gKnJlc3VsdFJlbEluZm8sCiAJCQkJCQkJVHVwbGVU YWJsZVNsb3QgKipzbG90cywKQEAgLTE1ODgsMTQgKzE1ODksNiBAQCBFeGVjRm9yUG9ydGlv bk9mTGVmdG92ZXJzKE1vZGlmeVRhYmxlQ29udGV4dCAqY29udGV4dCwKIAkJbGVmdG92ZXJT bG90LT50dHNfaXNudWxsW2ZvclBvcnRpb25PZi0+cmFuZ2VWYXItPnZhcmF0dG5vIC0gMV0g PSBmYWxzZTsKIAkJRXhlY01hdGVyaWFsaXplU2xvdChsZWZ0b3ZlclNsb3QpOwogCi0JCS8q Ci0JCSAqIElmIHRoZXJlIGFyZSBwYXJ0aXRpb25zLCB3ZSBtdXN0IGluc2VydCBpbnRvIHRo ZSByb290IHRhYmxlLCBzbyB3ZQotCQkgKiBnZXQgdHVwbGUgcm91dGluZy4gV2UgYWxyZWFk eSBzZXQgdXAgbGVmdG92ZXJTbG90IHdpdGggdGhlIHJvb3QKLQkJICogdHVwbGUgZGVzY3Jp cHRvci4KLQkJICovCi0JCWlmIChyZXN1bHRSZWxJbmZvLT5yaV9Sb290UmVzdWx0UmVsSW5m bykKLQkJCXJlc3VsdFJlbEluZm8gPSByZXN1bHRSZWxJbmZvLT5yaV9Sb290UmVzdWx0UmVs SW5mbzsKLQogCQkvKgogCQkgKiBUaGUgc3RhbmRhcmQgc2F5cyB0aGF0IGVhY2ggdGVtcG9y YWwgbGVmdG92ZXIgc2hvdWxkIGV4ZWN1dGUgaXRzCiAJCSAqIG93biBJTlNFUlQgc3RhdGVt ZW50LCBmaXJpbmcgYWxsIHN0YXRlbWVudCBhbmQgcm93IHRyaWdnZXJzLCBidXQKZGlmZiAt LWdpdCBhL3NyYy9iYWNrZW5kL3BhcnNlci9hbmFseXplLmMgYi9zcmMvYmFja2VuZC9wYXJz ZXIvYW5hbHl6ZS5jCmluZGV4IGYwZTllYmFkZGQ1Li45ZTliN2ZiMThkMiAxMDA2NDQKLS0t IGEvc3JjL2JhY2tlbmQvcGFyc2VyL2FuYWx5emUuYworKysgYi9zcmMvYmFja2VuZC9wYXJz ZXIvYW5hbHl6ZS5jCkBAIC0xMzQ4LDggKzEzNDgsNyBAQCB0cmFuc2Zvcm1Gb3JQb3J0aW9u T2ZDbGF1c2UoUGFyc2VTdGF0ZSAqcHN0YXRlLAogCiAJYXR0YmFzZXR5cGUgPSBnZXRCYXNl VHlwZShhdHRyLT5hdHR0eXBpZCk7CiAKLQlyYW5nZVZhciA9IG1ha2VWYXIoCi0JCQkJCSAg IHJ0aW5kZXgsCisJcmFuZ2VWYXIgPSBtYWtlVmFyKHJ0aW5kZXgsCiAJCQkJCSAgIHJhbmdl X2F0dG5vLAogCQkJCQkgICBhdHRyLT5hdHR0eXBpZCwKIAkJCQkJICAgYXR0ci0+YXR0dHlw bW9kLApkaWZmIC0tZ2l0IGEvc3JjL2luY2x1ZGUvbm9kZXMvZXhlY25vZGVzLmggYi9zcmMv aW5jbHVkZS9ub2Rlcy9leGVjbm9kZXMuaAppbmRleCAxNzdkZWQ0ZTVjZC4uMDkwY2ZjY2Y2 NWYgMTAwNjQ0Ci0tLSBhL3NyYy9pbmNsdWRlL25vZGVzL2V4ZWNub2Rlcy5oCisrKyBiL3Ny Yy9pbmNsdWRlL25vZGVzL2V4ZWNub2Rlcy5oCkBAIC00MSw2ICs0MSw3IEBACiAjaW5jbHVk ZSAidXRpbHMvcmVsdHJpZ2dlci5oIgogI2luY2x1ZGUgInV0aWxzL3R5cGNhY2hlLmgiCiAK KwogLyoKICAqIGZvcndhcmQgcmVmZXJlbmNlcyBpbiB0aGlzIGZpbGUKICAqLwpkaWZmIC0t Z2l0IGEvc3JjL3Rlc3QvcmVncmVzcy9leHBlY3RlZC9mb3JfcG9ydGlvbl9vZi5vdXQgYi9z cmMvdGVzdC9yZWdyZXNzL2V4cGVjdGVkL2Zvcl9wb3J0aW9uX29mLm91dAppbmRleCA4YTI5 YTE5ZjUwMS4uMzFmNzcyYzcyM2QgMTAwNjQ0Ci0tLSBhL3NyYy90ZXN0L3JlZ3Jlc3MvZXhw ZWN0ZWQvZm9yX3BvcnRpb25fb2Yub3V0CisrKyBiL3NyYy90ZXN0L3JlZ3Jlc3MvZXhwZWN0 ZWQvZm9yX3BvcnRpb25fb2Yub3V0CkBAIC0xNjM2LDE3ICsxNjM2LDE3IEBAIENSRUFURSBU QUJMRSBmb3JfcG9ydGlvbl9vZl90ZXN0ICgKIElOU0VSVCBJTlRPIGZvcl9wb3J0aW9uX29m X3Rlc3QgKGlkLCB2YWxpZF9hdCwgbmFtZSkgVkFMVUVTCiAgICgnWzEsMiknLCAnWzIwMTgt MDEtMDEsMjAyMC0wMS0wMSknLCAnb25lJyk7CiBDUkVBVEUgQ09OU1RSQUlOVCBUUklHR0VS IGZwb19hZnRlcl9pbnNlcnRfcm93Ci1BRlRFUiBJTlNFUlQgT04gZm9yX3BvcnRpb25fb2Zf dGVzdAotREVGRVJSQUJMRSBJTklUSUFMTFkgREVGRVJSRUQKLUZPUiBFQUNIIFJPVyBFWEVD VVRFIFBST0NFRFVSRSBkdW1wX3RyaWdnZXIoZmFsc2UsIGZhbHNlKTsKKyAgQUZURVIgSU5T RVJUIE9OIGZvcl9wb3J0aW9uX29mX3Rlc3QKKyAgREVGRVJSQUJMRSBJTklUSUFMTFkgREVG RVJSRUQKKyAgRk9SIEVBQ0ggUk9XIEVYRUNVVEUgUFJPQ0VEVVJFIGR1bXBfdHJpZ2dlcihm YWxzZSwgZmFsc2UpOwogQ1JFQVRFIENPTlNUUkFJTlQgVFJJR0dFUiBmcG9fYWZ0ZXJfdXBk YXRlX3JvdwotQUZURVIgVVBEQVRFIE9OIGZvcl9wb3J0aW9uX29mX3Rlc3QKLURFRkVSUkFC TEUgSU5JVElBTExZIERFRkVSUkVECi1GT1IgRUFDSCBST1cgRVhFQ1VURSBQUk9DRURVUkUg ZHVtcF90cmlnZ2VyKGZhbHNlLCBmYWxzZSk7CisgIEFGVEVSIFVQREFURSBPTiBmb3JfcG9y dGlvbl9vZl90ZXN0CisgIERFRkVSUkFCTEUgSU5JVElBTExZIERFRkVSUkVECisgIEZPUiBF QUNIIFJPVyBFWEVDVVRFIFBST0NFRFVSRSBkdW1wX3RyaWdnZXIoZmFsc2UsIGZhbHNlKTsK IENSRUFURSBDT05TVFJBSU5UIFRSSUdHRVIgZnBvX2FmdGVyX2RlbGV0ZV9yb3cKLUFGVEVS IERFTEVURSBPTiBmb3JfcG9ydGlvbl9vZl90ZXN0Ci1ERUZFUlJBQkxFIElOSVRJQUxMWSBE RUZFUlJFRAotRk9SIEVBQ0ggUk9XIEVYRUNVVEUgUFJPQ0VEVVJFIGR1bXBfdHJpZ2dlcihm YWxzZSwgZmFsc2UpOworICBBRlRFUiBERUxFVEUgT04gZm9yX3BvcnRpb25fb2ZfdGVzdAor ICBERUZFUlJBQkxFIElOSVRJQUxMWSBERUZFUlJFRAorICBGT1IgRUFDSCBST1cgRVhFQ1VU RSBQUk9DRURVUkUgZHVtcF90cmlnZ2VyKGZhbHNlLCBmYWxzZSk7CiBCRUdJTjsKIFVQREFU RSBmb3JfcG9ydGlvbl9vZl90ZXN0CiAgIEZPUiBQT1JUSU9OIE9GIHZhbGlkX2F0IEZST00g JzIwMTgtMDEtMTUnIFRPICcyMDE5LTAxLTAxJwpkaWZmIC0tZ2l0IGEvc3JjL3Rlc3QvcmVn cmVzcy9zcWwvZm9yX3BvcnRpb25fb2Yuc3FsIGIvc3JjL3Rlc3QvcmVncmVzcy9zcWwvZm9y X3BvcnRpb25fb2Yuc3FsCmluZGV4IDIwZDdlODc5YzE0Li5kNDA2MmFjZjFkMSAxMDA2NDQK LS0tIGEvc3JjL3Rlc3QvcmVncmVzcy9zcWwvZm9yX3BvcnRpb25fb2Yuc3FsCisrKyBiL3Ny Yy90ZXN0L3JlZ3Jlc3Mvc3FsL2Zvcl9wb3J0aW9uX29mLnNxbApAQCAtMTAzNywxOSArMTAz NywxOSBAQCBDUkVBVEUgVEFCTEUgZm9yX3BvcnRpb25fb2ZfdGVzdCAoCiAgICgnWzEsMikn LCAnWzIwMTgtMDEtMDEsMjAyMC0wMS0wMSknLCAnb25lJyk7CiAKIENSRUFURSBDT05TVFJB SU5UIFRSSUdHRVIgZnBvX2FmdGVyX2luc2VydF9yb3cKLUFGVEVSIElOU0VSVCBPTiBmb3Jf cG9ydGlvbl9vZl90ZXN0Ci1ERUZFUlJBQkxFIElOSVRJQUxMWSBERUZFUlJFRAotRk9SIEVB Q0ggUk9XIEVYRUNVVEUgUFJPQ0VEVVJFIGR1bXBfdHJpZ2dlcihmYWxzZSwgZmFsc2UpOwor ICBBRlRFUiBJTlNFUlQgT04gZm9yX3BvcnRpb25fb2ZfdGVzdAorICBERUZFUlJBQkxFIElO SVRJQUxMWSBERUZFUlJFRAorICBGT1IgRUFDSCBST1cgRVhFQ1VURSBQUk9DRURVUkUgZHVt cF90cmlnZ2VyKGZhbHNlLCBmYWxzZSk7CiAKIENSRUFURSBDT05TVFJBSU5UIFRSSUdHRVIg ZnBvX2FmdGVyX3VwZGF0ZV9yb3cKLUFGVEVSIFVQREFURSBPTiBmb3JfcG9ydGlvbl9vZl90 ZXN0Ci1ERUZFUlJBQkxFIElOSVRJQUxMWSBERUZFUlJFRAotRk9SIEVBQ0ggUk9XIEVYRUNV VEUgUFJPQ0VEVVJFIGR1bXBfdHJpZ2dlcihmYWxzZSwgZmFsc2UpOworICBBRlRFUiBVUERB VEUgT04gZm9yX3BvcnRpb25fb2ZfdGVzdAorICBERUZFUlJBQkxFIElOSVRJQUxMWSBERUZF UlJFRAorICBGT1IgRUFDSCBST1cgRVhFQ1VURSBQUk9DRURVUkUgZHVtcF90cmlnZ2VyKGZh bHNlLCBmYWxzZSk7CiAKIENSRUFURSBDT05TVFJBSU5UIFRSSUdHRVIgZnBvX2FmdGVyX2Rl bGV0ZV9yb3cKLUFGVEVSIERFTEVURSBPTiBmb3JfcG9ydGlvbl9vZl90ZXN0Ci1ERUZFUlJB QkxFIElOSVRJQUxMWSBERUZFUlJFRAotRk9SIEVBQ0ggUk9XIEVYRUNVVEUgUFJPQ0VEVVJF IGR1bXBfdHJpZ2dlcihmYWxzZSwgZmFsc2UpOworICBBRlRFUiBERUxFVEUgT04gZm9yX3Bv cnRpb25fb2ZfdGVzdAorICBERUZFUlJBQkxFIElOSVRJQUxMWSBERUZFUlJFRAorICBGT1Ig RUFDSCBST1cgRVhFQ1VURSBQUk9DRURVUkUgZHVtcF90cmlnZ2VyKGZhbHNlLCBmYWxzZSk7 CiAKIEJFR0lOOwogVVBEQVRFIGZvcl9wb3J0aW9uX29mX3Rlc3QKLS0gCjIuNTMuMAoK --------------mEKjZoTVh3EJhp3MeaaSKxBS--