Hi,
On 2/11/23 13:08, Dmitry Dolgov wrote:
On Sat, Feb 11, 2023 at 11:47:07AM +0100, Dmitry Dolgov wrote:
The original version of the patch was doing all of this, i.e. handling
numerics, Param nodes, RTE_VALUES. The commentary about
find_const_walker in tests is referring to a part of that, that was
dealing with evaluation of expression to see if it could be reduced to a
constant.
Unfortunately there was a significant push back from reviewers because
of those features. That's why I've reduced the patch to it's minimally
useful version, having in mind re-implementing them as follow-up patches
in the future. This is the reason as well why I left tests covering all
this missing functionality -- as breadcrumbs to already discovered
cases, important for the future extensions.
I'd like to elaborate on this a bit and remind about the origins of the
patch, as it's lost somewhere in the beginning of the thread. The idea
is not pulled out of thin air, everything is coming from our attempts to
improve one particular monitoring infrastructure in a real commercial
setting. Every covered use case and test in the original proposal was a
result of field trials, when some application-side library or ORM was
responsible for gigabytes of data in pgss, chocking the monitoring agent.
Thanks for the clarifications. I didn't mean to contend the usefulness
of the patch and I wasn't aware that you already jumped through the
loops of handling Param, etc. 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))
--
David Geier
(ServiceNow)
