On 2025-May-02, Michael Paquier wrote:
> That depends. If we conclude that tracking this information through
> the parser based on the start and end positions in a query string
> for a set of values is more relevant, then we would be redesigning the
> facility from the ground, so the old approach
> On Fri, May 02, 2025 at 04:18:37PM GMT, Michael Paquier wrote:
> On Fri, May 02, 2025 at 09:13:39AM +0200, Dmitry Dolgov wrote:
> > Squashing constants was ment to be a first step towards doing the same
> > for other types of queries (params, rte_values), reverting it to
> > implement everything
On Fri, May 02, 2025 at 09:13:39AM +0200, Dmitry Dolgov wrote:
> Squashing constants was ment to be a first step towards doing the same
> for other types of queries (params, rte_values), reverting it to
> implement everything at once makes very little sense to me.
That depends. If we conclude tha
> On Fri, May 02, 2025 at 07:10:19AM GMT, Michael Paquier wrote:
> > I am really leaning towards that we should revert this feature as the
> > limitation we have now with parameters is a rather large one and I think
> > we need to go back and address this issue.
>
> I am wondering if this would not
On Thu, May 01, 2025 at 03:57:16PM -0500, Sami Imseih wrote:
> I think what we should really allow the broader scope of expressions that
> are allowed via prepared statements, and this will make this implementation
> consistent between prepared vs non-prepared statements. I don't see why
> not. In
I spent a few hours looking into this today and to your points below:
> > I agree that the current solution we have in the tree feels incomplete
> > because we are not taking into account the most common cases that
> > users would care about. Now, allowing PARAM_EXTERN means that we
> > allow any
> On Thu, May 01, 2025 at 09:29:13AM GMT, Michael Paquier wrote:
>
> I agree that the current solution we have in the tree feels incomplete
> because we are not taking into account the most common cases that
> users would care about. Now, allowing PARAM_EXTERN means that we
> allow any expression
On Wed, Apr 30, 2025 at 04:52:06PM -0500, Sami Imseih wrote:
> 62d712ec added the ability to squash constants from an IN LIST
> for queryId computation purposes. This means that a similar
> queryId will be generated for the same queries that only
> different on the number of values in the IN-LIST.
