Re: general purpose array_sort

Aleksander Alekseev <aleksander@timescale.com>

From: Aleksander Alekseev <aleksander@timescale.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: jian he <jian.universality@gmail.com>, Junwang Zhao <zhjwpku@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, "David G. Johnston" <david.g.johnston@gmail.com>, Amit Langote <amitlangote09@gmail.com>, "andreas@proxel.se" <andreas@proxel.se>, Robert Haas <robertmhaas@gmail.com>
Date: 2024-10-29T12:14:42Z
Lists: pgsql-hackers
Hi Jian,

> IMMUTABLE indicates that the function cannot modify the database and always
> returns the same result when given the same argument values; that is, it does
> not do database lookups or otherwise use information not directly present in its
> argument list. If this option is given, any call of the function with
> all-constant arguments can be immediately replaced with the function value.
>
>
> + {
> + typentry = lookup_type_cache(elmtyp, TYPECACHE_LT_OPR);
> + if (!OidIsValid(typentry->lt_opr))
> + ereport(ERROR,
> + (errcode(ERRCODE_UNDEFINED_FUNCTION),
> + errmsg("could not identify ordering operator for type %s",
> + format_type_be(elmtyp))));
>
> This error can happen. I think this conflicts with the doc IMMUTABLE
> description.

lookup_type_cache() is used at least by array_position() which is
marked as IMMUTABLE, so I believe this is fine. Similarly functions
dealing with timezones can return different results between the DBMS
restarts / updates, but we don't care and mark them IMMUTABLE anyway.
Otherwise we couldn't use these functions in functional indexes which
will make them rather useless.

-- 
Best regards,
Aleksander Alekseev



Commits

  1. Introduce a SQL-callable function array_sort(anyarray).

  2. Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input.

  3. Re-implement the ereport() macro using __VA_ARGS__.