Re: general purpose array_sort - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: general purpose array_sort
Date
Msg-id CAJ7c6TMBX_dn_mnUv2C=g=nUkERes-qvRW6TAvf48qiymY4PrA@mail.gmail.com
Whole thread Raw
In response to Re: general purpose array_sort  (jian he <jian.universality@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Marcos Pegoraro
Date:
Subject: Re: [PATCH] Rename trim_array() for consistency with the rest of array_* functions
Next
From: Nikita Malakhov
Date:
Subject: Re: detoast datum into the given buffer as a optimization.