<p dir="ltr">On Jul 17, 2015 4:31 PM, "Andrew Dunstan" <<a
href="mailto:andrew@dunslane.net">andrew@dunslane.net</a>>wrote:<br /> ><br /> ><br /> > On 07/17/2015
10:11AM, Andrew Dunstan wrote:<br /> >><br /> >><br /> >> On 07/17/2015 08:20 AM, Shulgin, Oleksandr
wrote:<br/> >><br /> >><br /> >>> > This patch makes Postgres core more complex<br />
>>><br/> >>> Yes, it does. But, that was not the purpose, obviously. :-)<br /> >>><br />
>>>> while not really solving the problem in Javascript.<br /> >>><br /> >>> It still
allowsfor less risk of silent data corruption on the js side.<br /> >>><br /> >>><br /> >><br
/>>> I have already pointed out how this patch is fundamentally broken. You can achieve your aims by a fairly
smallamount of code inside your logical decoder, and with no core code changes whatsoever. So I'm puzzled why we are
evenstill debating this broken design.<br /> ><br /> ><br /> ><br /> > Incidentally, this doesn't look
acceptableanyway:<br /> >><br /> >> !
es->json_cxt.value(&es->json_cxt,num, JSONTYPE_NUMERIC,<br /> >> !
NUMERICOID, 1702 /* numeric_out */);<br /> ><br /> ><br /> > We don't
hardcodefunction oids elsewhere. So this is also something that makes the patch unacceptable.<p dir="ltr">Well, good to
know(I believe I've asked about this in the first mail specifically).<p dir="ltr">Is there any way a built-in function
oidwould change/differ on different server versions? What would be the recommended way to do this?<p dir="ltr">--<br />
Alex<br/>