From: | Aleksander Alekseev <aleksander(at)tigerdata(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, John Naylor <johncnaylorls(at)gmail(dot)com> |
Subject: | Re: [PATCH] Refactor bytea_sortsupport(), take two |
Date: | 2025-09-16 09:08:57 |
Message-ID: | CAJ7c6TNMq+2Xbstg9BrxQR6p5NUGXXpdGfWJSy5ni6b8-D4w-A@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Chao,
> 1.
> ····
> + /* We can't afford to leak memory here. */
> + if (PointerGetDatum(arg1) != x)
> + pfree(arg1);
> + if (PointerGetDatum(arg2) != y)
> + pfree(arg2);
> ···
>
> Should we do:
> ```
> PG_FREE_IF_COPY(arg1, 0);
> PG_FREE_IF_COPY(arg2, 1)
> ```
>
> Similar to other places.
Hmmm... to me it doesn't look more readable to be honest. I choose the
same pattern used in varlena.c and suggest keeping it for consistency.
IMO this refactoring can be discussed later in a separate thread. Good
observation though.
> 2.
> ···
> +/*
> + * Conversion routine for sortsupport.
> + */
> +static Datum
> +bytea_abbrev_convert(Datum original, SortSupport ssup)
> ···
>
> The function comment is less descriptive. I would suggest something like:
> ```
> /*
> * Abbreviated key conversion for bytea sortsupport.
> *
> * Returns the abbreviated key as a Datum. If a detoasted copy was made,
> * it is freed before returning.
> */
> ```
Sorry, but I don't think I agree with this either. The comment you are
proposing exposes the implementation details. I don't think that the
caller needs to know them.
This is basically a simplified varstr_abbrev_convert(). I was not
certain if I should mention this in a comment and/or how much text I
should copy from the comment for varstr_abbrev_convert(). I'm open to
suggestions.
> 3.
> ```
> + if (abbrev_distinct <= 1.0)
> + abbrev_distinct = 1.0;
> +
> + if (key_distinct <= 1.0)
> + key_distinct = 1.0;
> ```
>
> Why <= 1.0 then set to 1.0? Shouldn't “if" takes just <1.0?
Good point. I'll fix this in v4. Also I'll modify
varstr_abbrev_abort() for consistency.
One could argue that the change of varstr_abbrev_abort() is irrelevant
in the context of this patch. If there are objections we can easily
change '<' back to '<='. It's not that important but '<' looks cleaner
IMO.
> 4.
> ```
> Datum
> bytea_sortsupport(PG_FUNCTION_ARGS)
> {
> SortSupport ssup = (SortSupport) PG_GETARG_POINTER(0);
> MemoryContext oldcontext;
> + ByteaSortSupport *bss;
> ```
>
> “Bss” can be defined in the “if” clause where it is used.
Agree. I'll fix this in v4.
> 5.
> ```
> Datum
> bytea_sortsupport(PG_FUNCTION_ARGS)
> {
> SortSupport ssup = (SortSupport) PG_GETARG_POINTER(0);
> MemoryContext oldcontext;
> + ByteaSortSupport *bss;
> + bool abbreviate = ssup->abbreviate;
> ```
>
> The local variable “abbreviate” is only used once, do we really need to cache ssup->abbreviate into a local variable?
Agree, thanks.
--
Best regards,
Aleksander Alekseev
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2025-09-16 09:21:04 | Re: GB18030-2022 Support in PostgreSQL |
Previous Message | Peter Eisentraut | 2025-09-16 09:03:23 | Re: Cannot find a working 64-bit integer type on Illumos |