On 3 February 2018 at 23:17, Peter Geoghegan wrote:
> On Sat, Feb 3, 2018 at 2:15 PM, Simon Riggs wrote:
>>> I started looking at SQL Server's MERGE to verify that it also does
>>> not impose any restrictions on subselects in a MERGE UPDATE's
>>> targetlist, just like Oracle. Unsurprisingly, it d
On 4 February 2018 at 06:32, Amit Kapila wrote:
> On Wed, Jan 31, 2018 at 11:37 PM, Peter Geoghegan wrote:
>> On Wed, Jan 31, 2018 at 7:17 AM, Robert Haas wrote:
>>> I don't fully grok merge but suppose you have:
>>>
>>> WHEN MATCHED AND a = 0 THEN UPDATE ...
>>> WHEN MATCHED AND a = 1 THEN UPDA
On 3 February 2018 at 23:17, Peter Geoghegan wrote:
> There are 3 specific issues on query structure, that together paint a
> picture about what you're not doing in the optimizer:
>
> 1. Whether or not subselects in the UPDATE targetlist are supported.
>
> 2. Whether or not subselects in the WHEN
I recently had to build ed25519 digital signature validation in PostgreSQL.
Since pgcrypto doesn't
support these methods, I had to look into PL/Python and PL/v8 based
implementations. The
experience turned out to be very poor (documented here:
https://gist.github.com/nileshtrivedi
/7cd622d4d5219865
Simon Riggs writes:
> It will likely take some time to work through these and the current
> work items but will fix.
>
> Do you have the DDL so we can recreate these easily?
Attached are testcases that trigger the assertions when run against an
empty database instead of the one left behind by mak
On 2/2/18, Dean Rasheed wrote:
> I think it would be better to try to come up with an alternative
> algorithm that has a better theoretical basis, and then test that to
> see how it holds up in practice.
>
> With that in mind, attached is a patch based on the idea of setting a
> bound on the relat
On Fri, Jan 26, 2018 at 1:23 PM, Andrew Dunstan
wrote:
> Yeah, thanks. revised patch attached
FYI the identity regression test started failing recently with this
patch applied (maybe due to commit
533c5d8bddf0feb1785b3da17c0d17feeaac76d8?)
***
/home/travis/build/postgresql-cfbot/postgresql/src/
On Thu, Feb 1, 2018 at 6:01 PM, Marina Polyakova
wrote:
> This is the 8-th version of the patch for the precalculation of stable or
> immutable functions, stable or immutable operators and other nonvolatile
> expressions. This is a try to fix the most problems (I'm sorry, it took some
> time..) th
On Mon, Feb 5, 2018 at 7:19 AM, Thomas Munro
wrote:
> On Fri, Jan 26, 2018 at 1:23 PM, Andrew Dunstan
> wrote:
>> Yeah, thanks. revised patch attached
>
> FYI the identity regression test started failing recently with this
> patch applied (maybe due to commit
> 533c5d8bddf0feb1785b3da17c0d17feeaa
On Sun, Feb 4, 2018 at 12:42 AM, Simon Riggs wrote:
> I'm happy to quote your words.
>
> "I've acknowledged that the standard has something to
> say on this that supports your position, which has real weight."
>
> https://www.postgresql.org/message-id/CAH2-WzkAjSN1H-ym-sSDh%2B6EJWmEhyHdDStzXDB%2BF
On Fri, Feb 2, 2018 at 3:47 PM, Tsunakawa, Takayuki
wrote:
> The fix is to add PGTYPES_free() in libpgtypes.dll, just like libpq has
> PQfreemem() described here:
+#ifndef PGTYPES_FREE
+#define PGTYPES_FREE
+ extern void PGTYPES_free(void *ptr);
+#endif
It seems quite strange to repeat this in
On 2018/02/02 19:41, Stephen Frost wrote:
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
>> On 2018/01/23 8:57, Thomas Munro wrote:
>>> Here's an update to move the new stuff to the correct side of the
>>> closing "". Builds for me, and the typesetting looks OK.
>>> I'm not sure why the p
From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com]
> +#ifndef PGTYPES_FREE
> +#define PGTYPES_FREE
> + extern void PGTYPES_free(void *ptr);
> +#endif
>
> It seems quite strange to repeat this in pgtypes_date.h, pgtypes_interval.h
> and pgtypes_numeric.h. I guess you might not want to intro
>On Tue, Jan 30, 2018 at 3:37 AM, Yoshimi Ichiyanagi
> wrote:
>> Oracle and Microsoft SQL Server suported PMEM [1][2].
>> I think it is not too early for PostgreSQL to support PMEM.
>
>I agree; it's good to have the option available for those who have
>access to the hardware.
>
>If you haven't adde
From: Robert Haas [mailto:robertmh...@gmail.com]
> Temporary tables contain XIDs, so they need to be vacuumed for XID
> wraparound. Otherwise, queries against those tables by the session
> that created them could yield wrong answers. However, autovacuum
> can't perform that vacuuming; it would ha
On Thu, Feb 1, 2018 at 2:23 PM, Amit Langote
wrote:
>
> Yeah, the patch in its current form is wrong, because it will give wrong
> answers if the operator being used in a SAOP is non-strict. I modified
> the patch to consider operator strictness before doing anything with nulls.
That's fine, but
On 2018/02/05 13:20, Ashutosh Bapat wrote:
> On Thu, Feb 1, 2018 at 2:23 PM, Amit Langote
> wrote:
>>
>> Yeah, the patch in its current form is wrong, because it will give wrong
>> answers if the operator being used in a SAOP is non-strict. I modified
>> the patch to consider operator strictness
On Fri, Feb 2, 2018 at 11:13 PM, Claudio Freire wrote:
> On Thu, Feb 1, 2018 at 9:34 PM, Masahiko Sawada wrote:
>> On Mon, Jan 29, 2018 at 11:31 PM, Claudio Freire
>> wrote:
>>> On Mon, Jan 29, 2018 at 4:12 AM, Masahiko Sawada
>>> wrote:
On Sat, Jul 29, 2017 at 9:42 AM, Claudio Freire
Fujita-san,
Thank you for the review.
On 2018/02/02 19:56, Etsuro Fujita wrote:
> (2018/01/30 18:52), Etsuro Fujita wrote:
>> (2018/01/30 18:39), Amit Langote wrote:
>>> Will wait for your comments before sending a new version then.
>>
>> Ok, I'll post my comments as soon as possible.
>
> * Exec
Hi,
Thank you all for this so warm reception for my very first patch.
Thanks Stephen to have thought to add that patch to the commit fest. As it
was committed Friday, I was able to tell the whole story in my talk and
that's great.
And thanks again to everyone who helped me with that patch.
Regard
Hi all,
Many threads have touched $subject:
https://www.postgresql.org/message-id/CAN-RpxDPE4baiMMJ6TLd6AiUvrG=yrc05tgxrgp4auuth9j...@mail.gmail.com
https://www.postgresql.org/message-id/7c50423.5ad0.15e8b308b2f.coremail.chjis...@163.com
https://www.postgresql.org/message-id/1516736993.5599.4.ca..
Hi all,
While hacking some stuff, I bumped into the following:
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -1932,7 +1932,7 @@ ZeroMultiXactMemberPage(int pageno, bool writeXlog)
* MaybeExtendOffsetSlru
* Extend the offsets SLRU area,
2018-01-31 14:09 GMT+01:00 Pavel Stehule :
>
>
> 2018-01-31 13:58 GMT+01:00 Daniel Verite :
>
>> Pavel Stehule wrote:
>>
>> > This format is too important, so some special short or long option can
>> be
>> > practical (it will be printed in help)
>> >
>> > some like --csv
>>
>> I guess -C/
23 matches
Mail list logo
