Michael Paquier writes:
> On Mon, Jul 08, 2024 at 12:20:30PM +0300, Aleksander Alekseev wrote:
> -and arrays of any of these types.
> +and also arrays and records of any of these types.
> This update of the docs is incorrect, no? Records could include much
> more types than the o
On Mon, Jul 08, 2024 at 08:54:31PM -0400, Tom Lane wrote:
> Don't recall right at this instant, but I've put myself down as
> reviewer of this patch to remind me to look at it in the next
> day or two.
Thanks for the update. WFM.
--
Michael
signature.asc
Description: PGP signature
Michael Paquier writes:
> I am not sure to get the concerns of upthread regarding the type
> caching in the context of an aggregate, which is the business with
> lookup_type_cache(), especially since there is a btree operator
> relying on record_cmp(). Tom, what were your concerns here?
Don't re
On Mon, Jul 08, 2024 at 12:20:30PM +0300, Aleksander Alekseev wrote:
> Here is the corrected patch.
313f87a17155 is one example of a similar change with pg_lsn, with four
entries added to pg_proc and two to pg_aggregate. That's what this
patch is doing from what I can see.
-and arrays of
Hi,
> Many thanks. Here is the corrected patch. Now it also includes MIN()
> support and tests.
Michael Paquier (cc:'ed) commented offlist that I forgot to change the
documentation.
Here is the corrected patch.
--
Best regards,
Aleksander Alekseev
v3-0001-Support-min-record-and-max-record-ag
Hi,
> I don't see any copying happening in, say, text_larger or
> numeric_larger, so this shouldn't need to either.
>
> Personally I'd write "record_cmp(fcinfo) > 0" rather than indirecting
> through record_gt. The way you have it is not strictly correct anyhow:
> you're cheating by not using Dir
Aleksander Alekseev writes:
> One thing I'm not 100% sure of is whether record_larger() should make
> a copy of its arguments or the current implementation is safe.
I don't see any copying happening in, say, text_larger or
numeric_larger, so this shouldn't need to either.
Personally I'd write "r
Hi,
> Exactly Tom, I see no fundamental problem for it not to be implemented, since
> comparison operator is already implemented. In fact, MIN/MAX should work for
> all types for which comparison operator is defined.
On second thought, this should work reasonably well.
PFA a WIP patch. At this
Exactly Tom, I see no fundamental problem for it not to be implemented,
since comparison operator is already implemented. In fact, MIN/MAX should
work for all types for which comparison operator is defined.
Regarding index support, there should not be an issue if the index is
defined for the recor
Aleksander Alekseev writes:
>> In my queries I often need to do MIN/MAX for tuples, for example:
>> SELECT MAX(row(year, month))
>> FROM (VALUES(2025, 1), (2024,2)) x(year, month);
>> This query throws:
>> ERROR: function max(record) does not exist
>> Was this ever discussed or is there something
Hi,
> In my queries I often need to do MIN/MAX for tuples, for example:
>
> SELECT MAX(row(year, month))
> FROM (VALUES(2025, 1), (2024,2)) x(year, month);
>
> This query throws:
>
> ERROR: function max(record) does not exist
>
> In this case you can replace it with `MAX((year||'-'||month|
In my queries I often need to do MIN/MAX for tuples, for example:
SELECT MAX(row(year, month))
FROM (VALUES(2025, 1), (2024,2)) x(year, month);
This query throws:
ERROR: function max(record) does not exist
In this case you can replace it with `MAX((year||'-'||month||'-1')::date)`.
Howev
12 matches
Mail list logo
