From: Tom Lane <tgl@sss.pgh.pa.us>
To: jinser <aimer@purejs.icu>
cc: pgsql-novice@lists.postgresql.org
Subject: Re: Is `DATE` a function?
In-reply-to: 
 <CAK3STzGm-8_5yvyWm_SJALo1Wb1i3cMJrBj8=WPmVyxHdhmYrg@mail.gmail.com>
References: 
 <CAK3STzGm-8_5yvyWm_SJALo1Wb1i3cMJrBj8=WPmVyxHdhmYrg@mail.gmail.com>
Comments: In-reply-to jinser <aimer@purejs.icu>
	message dated "Sat, 07 Oct 2023 21:01:59 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3126566.1696689510.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 07 Oct 2023 10:38:30 -0400
Message-ID: <3126567.1696689510@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3126567.1696689510%40sss.pgh.pa.us>
Precedence: bulk

jinser <aimer@purejs.icu> writes:
> playground=3D# SELECT DATE('2022-01-13');
>     date
> ------------
>  2022-01-13
> (1 row)

Sure, there are functions named date():

postgres=3D# \df date
                             List of functions
   Schema   | Name | Result data type |     Argument data types     | Type=
 =

------------+------+------------------+-----------------------------+-----=
-
 pg_catalog | date | date             | timestamp with time zone    | func
 pg_catalog | date | date             | timestamp without time zone | func
(2 rows)

The reason these aren't explicitly documented is that they are intended as
implementation support for casts.

postgres=3D# \dC date
                                      List of casts
         Source type         |         Target type         |  Function   |=
   Implicit?   =

-----------------------------+-----------------------------+-------------+=
---------------
 date                        | timestamp with time zone    | timestamptz |=
 yes
 date                        | timestamp without time zone | timestamp   |=
 yes
 timestamp with time zone    | date                        | date        |=
 in assignment
 timestamp without time zone | date                        | date        |=
 in assignment
(4 rows)

Hence, the preferred spelling is more like

	select now()::date;

or if you want to be SQL-spec-compatible,

	select cast(now() as date);

but for historical reasons we like to let you also write

	select date(now());

which is managed (in most cases) by naming cast implementation
functions the same as the target type.

> Another reason I think this is a function is that other types don't
> seem to have the same behavior:

> playground=3D# SELECT integer('123');
> ERROR:  syntax error at or near "("

You're running into a couple of things there: INTEGER is a reserved
word, and the cast functions for that type are named after the
internal type name "int4".

postgres=3D# \dC integer
                              List of casts
   Source type    |   Target type    |      Function      |   Implicit?   =

------------------+------------------+--------------------+---------------
 "char"           | integer          | int4               | no
 bigint           | integer          | int4               | in assignment
 bit              | integer          | int4               | no
 boolean          | integer          | int4               | no
 double precision | integer          | int4               | in assignment
 integer          | "char"           | char               | no
 ...

postgres=3D# select int4('123');
 int4 =

------
  123
(1 row)

Note that none of these have anything to do with the syntax for
a typed literal, which is "type-name quoted-literal" with no
parentheses:

postgres=3D# select date 'today';
    date    =

------------
 2023-10-07
(1 row)

postgres=3D# select integer '42';
 int4 =

------
   42
(1 row)

Some aspects of the behavior might look the same, but there
are a lot of edge cases.

			regards, tom lane