Anastasia Lubennikova writes:
> On 31.03.2020 23:45, Tom Lane wrote:
>> Still haven't got a better naming idea, but in the meantime here's
>> a rebase to fix a conflict with 612a1ab76.
> Maybe "amadjustmembers" will work?
Not having any better idea, I adopted that one.
> I've looked through the
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Looks good to me.
CORRECTION:
In my previous review I had mistakenl
On Tue, Jul 28, 2020 at 8:43 PM Tom Lane wrote:
> Hamid Akhtar writes:
> > I've gone through the patch and applied on the master branch, other than
> a few hunks, and whether as suggested upthread, the default case for
> "switch (op->number)" should throw an error or not, I found that bloom
> re
Hamid Akhtar writes:
> I've gone through the patch and applied on the master branch, other than a
> few hunks, and whether as suggested upthread, the default case for "switch
> (op->number)" should throw an error or not, I found that bloom regression is
> crashing.
> -
> test bloom
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: not tested
Documentation:not tested
I've gone through the patch and applied on the master branch, other t
On 31.03.2020 23:45, Tom Lane wrote:
I wrote:
Still haven't got a better naming idea, but in the meantime here's
a rebase to fix a conflict with 612a1ab76.
Maybe "amadjustmembers" will work?
I've looked through the patch and noticed this comment:
+ default:
+ /* Pro
Alvaro Herrera writes:
> On 2019-Aug-18, Tom Lane wrote:
>> * I'm not at all impressed with the name, location, or concept of
>> opfam_internal.h. I think we should get rid of that header and put
>> the OpFamilyMember struct somewhere else. Given that this patch
>> makes it part of the AM API, i
On 2019-Aug-18, Tom Lane wrote:
> * I'm not at all impressed with the name, location, or concept of
> opfam_internal.h. I think we should get rid of that header and put
> the OpFamilyMember struct somewhere else. Given that this patch
> makes it part of the AM API, it wouldn't be unreasonable to
I wrote:
> Still haven't got a better naming idea, but in the meantime here's
> a rebase to fix a conflict with 612a1ab76.
I see from the cfbot that this needs another rebase, so here 'tis.
No changes in the patch itself.
regards, tom lane
diff --git a/contrib/bloom/bluti
Tomas Vondra writes:
> On Sun, Jan 05, 2020 at 12:33:10PM -0500, Tom Lane wrote:
>> I see your point that "check" suggests a read-only operation, but
>> I'm not sure about a better verb. I thought of "amvalidatemembers",
>> but that's not really much better than "check" is it?
> I don't :-(
Sti
On Sun, Jan 05, 2020 at 12:33:10PM -0500, Tom Lane wrote:
Tomas Vondra writes:
The latest version of this patch (from 2019/09/14) no longer applies,
although maybe it's some issue with patch format (applying it using
patch works fine, git am fails with "Patch format detection failed.").
Hm, s
Tomas Vondra writes:
> The latest version of this patch (from 2019/09/14) no longer applies,
> although maybe it's some issue with patch format (applying it using
> patch works fine, git am fails with "Patch format detection failed.").
Hm, seems to be just a trivial conflict against the copyright
Hi,
The latest version of this patch (from 2019/09/14) no longer applies,
although maybe it's some issue with patch format (applying it using
patch works fine, git am fails with "Patch format detection failed.").
In any case, this means cputube can't apply/test it.
On Sat, Sep 14, 2019 at 07:01:
Alexander Korotkov writes:
> On Sun, Aug 18, 2019 at 10:00 PM Tom Lane wrote:
>> * Are the specific ways that the entries are getting set up appropriate?
>> Note in particular that I left btree/hash alone, feeling that the default
>> (historical) behavior was designed for them and is not unreason
On Sun, Aug 18, 2019 at 10:00 PM Tom Lane wrote:
> Here's a preliminary patch along these lines. It adds an AM callback
> that can adjust the dependency types before they're entered into
> pg_depend. There's a lot of stuff that's open for debate and/or
> remains to be done:
>
> * Is the paramete
Alexander Korotkov writes:
> On Wed, Aug 7, 2019 at 7:28 PM Tom Lane wrote:
>> This leads to the thought that maybe we could put some intelligence
>> into an index-AM-specific callback instead. For example, for btree
>> and hash the appropriate rule is probably that cross-type operators
>> and f
>
> But none of our contrib modules do it like that, and I'd lay long odds
> against any third party code doing it either.
Thoughts?
>
PostGIS has some rarely used box operations as part of GiST opclass, like
"overabove".
These are source of misunderstanding, as it hinges on the fact that
non-
On Wed, Aug 7, 2019 at 7:28 PM Tom Lane wrote:
> Over in [1] we realized that it would be a good idea to remove the <@
> operator from contrib/intarray's GiST opclasses. Unfortunately, doing
> that isn't a simple matter of generating an extension update script
> containing ALTER OPERATOR FAMILY D
Over in [1] we realized that it would be a good idea to remove the <@
operator from contrib/intarray's GiST opclasses. Unfortunately, doing
that isn't a simple matter of generating an extension update script
containing ALTER OPERATOR FAMILY DROP OPERATOR, because that operator
is marked as interna
19 matches
Mail list logo
