jian he writes:
> I also made the following changes:
> from
> uint64 levelHash = hash_any_extended((unsigned char *) al->name, al->len,
> seed);
> uint32 levelHash = hash_any((unsigned char *) al->name, al->len);
> to
> uint64 levelHash = DatumGetUInt64(hash_any_extended((unsigned char *)
> al-
On Thu, Feb 1, 2024 at 11:11 PM vignesh C wrote:
>
> On Wed, 6 Dec 2023 at 04:08, Tommy Pavlicek wrote:
> >
> > Thanks.
> >
> > I've attached the latest version that updates the naming in line with
> > the convention.
> >
> > On Mon, Dec 4, 2023 at 12:46 AM jian he wrote:
> > >
> > > On Fri, Dec
On Wed, 6 Dec 2023 at 04:08, Tommy Pavlicek wrote:
>
> Thanks.
>
> I've attached the latest version that updates the naming in line with
> the convention.
>
> On Mon, Dec 4, 2023 at 12:46 AM jian he wrote:
> >
> > On Fri, Dec 1, 2023 at 8:44 AM Tommy Pavlicek wrote:
> > >
> > >
> > > Patch updat
Thanks.
I've attached the latest version that updates the naming in line with
the convention.
On Mon, Dec 4, 2023 at 12:46 AM jian he wrote:
>
> On Fri, Dec 1, 2023 at 8:44 AM Tommy Pavlicek wrote:
> >
> >
> > Patch updated for those comments (and a touch of cleanup in the tests)
> > attached.
On Fri, Dec 1, 2023 at 8:44 AM Tommy Pavlicek wrote:
>
>
> Patch updated for those comments (and a touch of cleanup in the tests)
> attached.
it would be a better name as hash_ltree than ltree_hash, similar logic
applies to ltree_hash_extended.
that would be the convention. see: https://stackove
On Tue, Nov 28, 2023 at 7:38 PM jian he wrote:
> you only change Makefile, you also need to change contrib/ltree/meson.build?
> Do you need to use EXPLAIN to demo the index usage?
Thanks! Yes, I missed the Meson build file. I added additional
commands with EXPLAIN (COSTS OFF) as I found in other
On Wed, Nov 29, 2023 at 6:09 AM Tommy Pavlicek wrote:
>
> On Thu, Jul 6, 2023 at 2:18 AM Daniel Gustafsson wrote:
> >
> > > On 19 Jun 2023, at 11:18, Tommy Pavlicek wrote:
> >
> > > Tommy, are you interested in extending ALTER OPERATOR to allow this,
> > > which would also allow fixing the ltree
On Thu, Jul 6, 2023 at 2:18 AM Daniel Gustafsson wrote:
>
> > On 19 Jun 2023, at 11:18, Tommy Pavlicek wrote:
>
> > Tommy, are you interested in extending ALTER OPERATOR to allow this,
> > which would also allow fixing the ltree operator?
> >
> > Yes, I can do that. I took a look over the code an
> On 19 Jun 2023, at 11:18, Tommy Pavlicek wrote:
> Tommy, are you interested in extending ALTER OPERATOR to allow this,
> which would also allow fixing the ltree operator?
>
> Yes, I can do that. I took a look over the code and email thread and it seems
> like it should be relatively straight
>
> FWIW the CREATE OPERATOR documentation only talks about hash joins for
HASHES, maybe it should be updated to also mention hash aggregates?
I think I might have been a bit unclear here, the hash aggregate does work
without altering the operator so it's just the join that's blocked. Sorry
abou
On 6/17/23 20:19, Tom Lane wrote:
> Tomas Vondra writes:
>> I guess the "correct" solution would be to extend ALTER OPERATOR. I
>> wonder why it's not supported - it's clearly an intentional decision
>> (per comment in AlterOperator). So what might break if this changes for
>> an existing opera
Tomas Vondra writes:
> I guess the "correct" solution would be to extend ALTER OPERATOR. I
> wonder why it's not supported - it's clearly an intentional decision
> (per comment in AlterOperator). So what might break if this changes for
> an existing operator?
This code was added by commit 321eed5
Hi,
I've created a CF entry for the patch:
https://commitfest.postgresql.org/43/4375/
I only briefly skimmed the code, so a couple comments.
On 6/17/23 17:45, Tommy Pavlicek wrote:
> Hi All,
>
> I've written a patch to add hash functions for the ltree extension. It
> adds support for hash in
13 matches
Mail list logo
