6 ms·
Not really, the ones calling down to date_trunc should be marked as STABLE, since the underlying function is STABLE. psql=$ \df+ date_trunc Schema |
by wulczer 13y ago
Not really, the ones calling down to date_trunc should be marked as STABLE, since the underlying function is STABLE.
psql=$ \df+ date_trunc
Schema | Name | Result data type | Argument data types | Type | Volatility | Owner | Language | Source code | Description
------------+------------+-----------------------------+-----------------------------------+--------+------------+----------+----------+-------------------+------------------------------------------------------
pg_catalog | date_trunc | interval | text, interval | normal | immutable | postgres | internal | interval_trunc | truncate interval to specified units
pg_catalog | date_trunc | timestamp without time zone | text, timestamp without time zone | normal | immutable | postgres | internal | timestamp_trunc | truncate timestamp to specified units
pg_catalog | date_trunc | timestamp with time zone | text, timestamp with time zone | normal | stable | postgres | internal | timestamptz_trunc | truncate timestamp with time zone to specified units
- jeltz 13y agoNo, the code casts to "timestamp without time zone" before running date_trunc so it is immutable. For example: CREATE OR REPLACE FUNCTION gd_day(timestamptz, text) RETURNS timestamptz AS $$ SELECT DATE_TRUNC('day', $1 AT TIME ZONE $2) AT TIME ZONE $2; $$ LANGUAGE SQL; EDIT: The reason that some time functions in PostgreSQL are not immutable is that they are affected by the current time zone setting of the session.