From: | Hédi HACHENI <hacheni(at)kopileft(dot)com> |
---|---|
To: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
Cc: | List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: JDBC and positioned updates |
Date: | 2015-12-26 08:53:03 |
Message-ID: | 567E556F.4020103@kopileft.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Basically we will not perform positioned updates on the hole table data
but for a data portion that it would not exceed 30 rows. That's why I
said it depends on what table we're going through.
But we take care about queries performances.
On 12/26/2015 09:21 AM, Vladimir Sitnikov wrote:
>> we cannot achieve positioned updates using the JDBC implementation
> This is "functional requirement"
>
>> All of these parameters depends on what table we're going through
> Those a "non-functional requirements" (see [1]).
> You'd better collect NFRs *before* you finalize design and write the code.
>
>> Our main problem is
> Suppose you somehow achieved "positional updates". What if it turns
> out to be super-slow? Believe me, there are good reasons for
> "positional updates" to be super slow.
> You would have to rewrite the whole thing from scratch to make it fast.
>
> This is why I do not want to help you to shoot into your own foot.
>
> Anyway, pull requests are welcome.
>
> [1]: https://en.wikipedia.org/wiki/Non-functional_requirement
>
> Vladimir
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Wooten | 2015-12-26 14:54:31 | Re: JDBC and positioned updates |
Previous Message | Vladimir Sitnikov | 2015-12-26 08:21:12 | Re: JDBC and positioned updates |