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
-
Introduce a SQL-callable function array_sort(anyarray).
- 6c12ae09f5a5 18.0 landed
-
Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input.
- 4618045bee4a 18.0 cited
-
Re-implement the ereport() macro using __VA_ARGS__.
- e3a87b4991cc 13.0 cited