On Mon, Aug 12, 2024 at 04:13:02PM +0300, Aleksander Alekseev wrote:
> Patch v5 LGTM.
Committed.
--
nathan
Hi,
> WFM. Here is what I have staged for commit.
Patch v5 LGTM.
--
Best regards,
Aleksander Alekseev
On Thu, Aug 08, 2024 at 10:49:42AM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> On Thu, Aug 08, 2024 at 04:27:20PM +0200, Peter Eisentraut wrote:
>>> The correct return type of a CRC operation in general is some kind of exact
>>> numerical type. Just pick the best one that fits the result.
Nathan Bossart writes:
> On Thu, Aug 08, 2024 at 04:27:20PM +0200, Peter Eisentraut wrote:
>> The correct return type of a CRC operation in general is some kind of exact
>> numerical type. Just pick the best one that fits the result. I don't think
>> bytea is appropriate.
> That would leave us
On Thu, Aug 08, 2024 at 04:27:20PM +0200, Peter Eisentraut wrote:
> On 05.08.24 17:28, Nathan Bossart wrote:
>> This looks pretty good to me. The only point that I think deserves more
>> discussion is the return type. Does bytea make the most sense here? Or
>> should we consider int/bigint?
>
>
On 05.08.24 17:28, Nathan Bossart wrote:
This looks pretty good to me. The only point that I think deserves more
discussion is the return type. Does bytea make the most sense here? Or
should we consider int/bigint?
The correct return type of a CRC operation in general is some kind of
exact
Hi,
> Yeah, I was surprised to learn there wasn't yet an easy way to do this.
> I'm not sure how much of a factor this should play in deciding the return
> value for the CRC functions, but IMHO it's a reason to reconsider returning
> text as you originally proposed.
OK, here is the corrected patc
On Tue, Aug 06, 2024 at 11:04:41AM +0300, Aleksander Alekseev wrote:
> Perhaps we need get_int4() / get_int8() / get_numeric() as there seems
> to be a demand [1][2] and it will allow us to easily cast a `bytea`
> value to `integer` or `bigint`. This is probably another topic though.
Yeah, I was s
Hi,
> This looks pretty good to me. The only point that I think deserves more
> discussion is the return type. Does bytea make the most sense here? Or
> should we consider int/bigint?
Personally I would choose BYTEA in order to be consistent with sha*() functions.
It can be casted to TEXT if
On Mon, Aug 05, 2024 at 04:19:45PM +0300, Aleksander Alekseev wrote:
> Thanks, PFA patch v3.
This looks pretty good to me. The only point that I think deserves more
discussion is the return type. Does bytea make the most sense here? Or
should we consider int/bigint?
--
nathan
Hi,
> I'm curious why we need to do this instead of only using the macros:
>
> INIT_TRADITIONAL_CRC32(crc);
> COMP_TRADITIONAL_CRC32(crc, VARDATA_ANY(in), len);
> FIN_TRADITIONAL_CRC32(crc);
>
> + * IDENTIFICATION
> + *src/backend/utils/adt/hashfuncs.c
>
> Perhaps these would fit i
+/*
+ * Calculate CRC32 of the given data.
+ */
+static inline pg_crc32
+crc32_sz(const char *buf, int size)
+{
+ pg_crc32crc;
+ const char *p = buf;
+
+ INIT_TRADITIONAL_CRC32(crc);
+ while (size > 0)
+ {
+ charc = (char) (*p);
+
+
Hi Nathan,
> I don't think adding crc32c() would sufficiently increase the scope. We'd
> use the existing implementations for both crc32() and crc32c(). And
> besides, this could be useful for adding tests for that code.
>
> +crc32 ( text )
>
> Do we need a version of the function that t
On Fri, Jul 26, 2024 at 12:01:40PM +0300, Aleksander Alekseev wrote:
>> This sounds generally reasonable to me, especially given the apparent
>> demand. Should we also introduce crc32c() while we're at it?
>
> Might be a good idea. However I didn't see a demand for crc32c() SQL
> function yet. Al
Hi,
> This sounds generally reasonable to me, especially given the apparent
> demand. Should we also introduce crc32c() while we're at it?
Might be a good idea. However I didn't see a demand for crc32c() SQL
function yet. Also I'm not sure whether the best interface for it
would be crc32c() or c
On Thu, Jul 18, 2024 at 02:24:23PM +0300, Aleksander Alekseev wrote:
> I vaguely recall that I faced this problem before. Supporting crc32
> was requested on the mailing list [2] and a number of workarounds
> exist in PL/pgSQL [3][4]. Since there seems to be a demand and it
> costs us nothing to ma
16 matches
Mail list logo
