Message-ID: <8702fa3e-5aac-dcf0-161b-faa2b9eadad6@gmail.com>
Date: Thu, 23 Feb 2023 09:48:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Subject: Re: pg_stat_statements and "IN" conditions
Content-Language: en-US
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Sergei Kornilov <sk@zsrv.org>, Michael Paquier <michael@paquier.xyz>,
 Alvaro Herrera <alvherre@alvh.no-ip.org>, Marcos Pegoraro
 <marcos@f10.com.br>, vignesh C <vignesh21@gmail.com>,
 Robert Haas <robertmhaas@gmail.com>, Zhihong Yu <zyu@yugabyte.com>,
 David Steele <david@pgmasters.net>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Greg Stark <stark@mit.edu>, Pavel Trukhanov <pavel.trukhanov@gmail.com>,
 Tom Lane <tgl@sss.pgh.pa.us>
References: <Y98GsRJoCM4RrcWp@paquier.xyz>
 <20230205113346.gmbf5ycnukuhnmqa@erthalion.local>
 <2420105.1675612952@sss.pgh.pa.us>
 <20230205195600.e3bhwszzm5kdyyxl@erthalion.local>
 <966631675800892@znolar4klagewshm.sas.yp-c.yandex.net>
 <20230209150238.rdtwruh5i34hdag5@ddolgov.remote.csb>
 <dda65b89-4ebf-261c-de9c-7b91ab9e4047@gmail.com>
 <20230211104707.grsicemegr7d3mgh@erthalion.local>
 <20230211120820.y7krq37jubnjsa5b@erthalion.local>
 <07919318-6c35-a13f-6a1d-98686a3e38de@gmail.com>
 <20230217154602.uf3a3cgqeoeysycz@erthalion.local>
From: David Geier <geidav.pg@gmail.com>
In-Reply-To: <20230217154602.uf3a3cgqeoeysycz@erthalion.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/8702fa3e-5aac-dcf0-161b-faa2b9eadad6%40gmail.com>
Precedence: bulk

Hi,

>> Seems like supporting only constants is a good starting
>> point. The only thing that is likely confusing for users is that NUMERICs
>> (and potentially constants of other types) are unsupported. Wouldn't it be
>> fairly simple to support them via something like the following?
>>
>>      is_const(element) || (is_coercion(element) && is_const(element->child))
> It definitely makes sense to implement that, although I don't think it's
> going to be acceptable to do that via directly listing conditions an
> element has to satisfy. It probably has to be more flexible, sice we
> would like to extend it in the future. My plan is to address this in a
> follow-up patch, when the main mechanism is approved. Would you agree
> with this approach?

I still think it's counterintuitive and I'm pretty sure people would 
even report this as a bug because not knowing about the difference in 
internal representation you would expect NUMERICs to work the same way 
other constants work. If anything we would have to document it.

Can't we do something pragmatic and have something like 
IsMergableInElement() which for now only supports constants and later 
can be extended? Or what exactly do you mean by "more flexible"?

-- 
David Geier
(ServiceNow)