Re: [PATCH] ltree hash functions

2024-03-21 Thread Tom Lane
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 *) >

Re: [PATCH] ltree hash functions

2024-02-04 Thread jian he
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,

Re: [PATCH] ltree hash functions

2024-02-01 Thread vignesh C
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

Re: [PATCH] ltree hash functions

2023-12-05 Thread Tommy Pavlicek
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) > >

Re: [PATCH] ltree hash functions

2023-12-03 Thread jian he
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:

Re: [PATCH] ltree hash functions

2023-11-30 Thread Tommy Pavlicek
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

Re: [PATCH] ltree hash functions

2023-11-28 Thread jian he
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

Re: [PATCH] ltree hash functions

2023-11-28 Thread Tommy Pavlicek
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

Re: [PATCH] ltree hash functions

2023-07-06 Thread Daniel Gustafsson
> 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

Re: [PATCH] ltree hash functions

2023-06-19 Thread Tommy Pavlicek
> > 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

Re: [PATCH] ltree hash functions

2023-06-17 Thread Tomas Vondra
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

Re: [PATCH] ltree hash functions

2023-06-17 Thread Tom Lane
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

Re: [PATCH] ltree hash functions

2023-06-17 Thread Tomas Vondra
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

[PATCH] ltree hash functions

2023-06-17 Thread Tommy Pavlicek
Hi All, I've written a patch to add hash functions for the ltree extension. It adds support for hash indexes and hash aggregation. I've reused the existing logic that's used to hash arrays and added tests that mirror elsewhere (i.e. hstore and hash_func regression tests). The patch doesn't