Hey, let me know if there's any way I can help.
I would argue that making even a small improvement here would be beneficial
to many.
On Tue, Jul 21, 2020 at 11:59 AM Dmitry Dolgov <9erthali...@gmail.com>
wrote:
> > On Thu, Oct 3, 2019 at 3:33 AM Pavel Trukhanov <
> pavel.trukha...@gmail.com> wro
> On Thu, Oct 3, 2019 at 3:33 AM Pavel Trukhanov
> wrote:
>
>> On Wed, Jun 26, 2019 at 11:10 PM Tom Lane wrote:
>>
>> Greg Stark writes:
>> > Actually thinking about this for two more seconds the question is what it
>> > would do with a query like
>> > WHERE col = ANY '1,2,3'::integer[]
>> > Or
Thanks for your input.
As for real-world applications – being a founder of a server monitoring
saas (okmeter) I have access to stats on hundreds of postgres installations.
It shows that IN with a variable number of params is ~7 times more used
than ANY(array).
On Wed, Jun 26, 2019 at 11:10 PM T
Greg Stark writes:
> Actually thinking about this for two more seconds the question is what it
> would do with a query like
> WHERE col = ANY '1,2,3'::integer[]
> Or
> WHERE col = ANY ARRAY[1,2,3]
> Whichever the language binding that is failing to do parameterized queries
> is doing to emulate th
On Sat., Jun. 15, 2019, 8:30 p.m. Greg Stark, wrote:
>
>
> So what would this do for someone who explicitly writes:
>
> WHERE col = ANY ?
>
> and pass an array?
>
Actually thinking about this for two more seconds the question is what it
would do with a query like
WHERE col = ANY '1,2,3'::intege
On Sat., Jun. 15, 2019, 12:29 p.m. Pavel Trukhanov, <
pavel.trukha...@gmail.com> wrote:
>
> So I don't think there's actually enough benefit to split those two apart.
>
> Now I want to do this: just add a meta info (basically a bool field)
> to the ArrayExpr struct, so on later stages we could tel
Thanks for the feedback.
I thought once again about separating IN from ARRAY, with refactoring
etc as Tom suggested, and now I don't think it's worth it to do so.
I've tried to implement that, and besides that it will require to
change things in every part of query processing pipeline, it seems
th
Pavel Trukhanov writes:
> Though I might've used wrong words to describe my holdback here, what
> I meant is that I'll need to create new node type (in primnodes.h?)
> for IN-list, that will allow to differentiate it from direct "ARRAY"
> usage.
> This will require changes to parse_expr.c, execExp
Thanks for your reply
> If I understand correctly, "IN (...)" is reprecented by A_Expr with kind
> AEXPR_IN, and only in transformAExprIn converted to ArrayExpr if possible.
That seems to be correct, yes, thank you.
> So probably it doesn't makes sense to introduce another one.
Though I might've
> On Thu, Jun 13, 2019 at 1:38 PM Pavel Trukhanov
> wrote:
>
> Hi Hackers
>
> I would like to embark on a journey to try to implement this issue I
> found on TODO list –
> https://www.postgresql.org/message-id/flat/CAM3SWZSpdPB3uErnXWMt3q74y0r%2B84ZsOt2U3HKKes_V7O%2B0Qg%40mail.gmail.com
> In shor
Hi Hackers
I would like to embark on a journey to try to implement this issue I
found on TODO list –
https://www.postgresql.org/message-id/flat/CAM3SWZSpdPB3uErnXWMt3q74y0r%2B84ZsOt2U3HKKes_V7O%2B0Qg%40mail.gmail.com
In short: pgss distinguishes "SELECT * WHERE id IN (1, 2)" and "SELECT
* WHERE id
11 matches
Mail list logo
