Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL);

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL);
Дата
Msg-id
3693246.1708193659@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); PG Bug reporting form <noreply@postgresql.org>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); David Rowley <dgrowleyml@gmail.com>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); jian he <jian.universality@gmail.com>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); Michael Bondarenko <work.michael.2956@gmail.com>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); Francisco Olarte <folarte@peoplecall.com>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); jian he <jian.universality@gmail.com>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); jian he <jian.universality@gmail.com>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); jian he <jian.universality@gmail.com>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); Tom Lane <tgl@sss.pgh.pa.us>
BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); "Wetmore, Matthew (CTR)" <Matthew.Wetmore@evernorth.com>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); jian he <jian.universality@gmail.com>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); jian he <jian.universality@gmail.com>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); Michael Bondarenko <work.michael.2956@gmail.com>
Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); David Rowley <dgrowleyml@gmail.com>
David Rowley  writes:
> On Sat, 17 Feb 2024 at 01:27, PG Bug reporting form
>  wrote:
>> Moreover, the documentation does not mention that the field cannot be
>> extracted from INTERVAL, like it does for isoyear:
>> https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT

> Maybe that table should specify which type(s) each of the items listed
> is applicable to. Seems better than mentioning which types they're not
> applicable to.

The thing's not laid out as a table though, and converting it seems
like more trouble than this is worth.  The rejected cases hardly seem
surprising.  I propose just mentioning that not all fields apply for
all data types, as in 0001 attached.

(Parenthetically, one case that perhaps is surprising is
	ERROR:  unit "week" not supported for type interval
Why not just return the day field divided by 7?)

Unrelated but adjacent, the discussion of the century field seems
more than a bit flippant when I read it now.  In other places we
are typically content to use examples to make similar points.
I propose doing so here too, as in 0002 attached.

Lastly, the entire page is quite schizophrenic about whether to leave
a blank line between adjacent examples.  I could go either way on
whether to have that whitespace or not, but I do think it would be
better to make it uniform.  Any votes on what to do there?

			regards, tom lane

diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index cf3de80394..fc8017f2f3 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -10040,13 +10040,19 @@ EXTRACT(field FROM source)
     The extract function retrieves subfields
     such as year or hour from date/time values.
     source must be a value expression of
-    type timestamp, time, or interval.
-    (Expressions of type date are
-    cast to timestamp and can therefore be used as
-    well.)  field is an identifier or
+    type timestamp, date, time,
+    or interval.  (Timestamps and times can be with or
+    without time zone.)
+    field is an identifier or
     string that selects what field to extract from the source value.
+    Not all fields are valid for every input data type; for example, fields
+    smaller than a day cannot be extracted from a date, while
+    fields of a day or more cannot be extracted from a time.
     The extract function returns values of type
     numeric.
+   
+
+   
     The following are valid field names:
 
     
@@ -10228,7 +10228,7 @@ SELECT EXTRACT(ISODOW FROM TIMESTAMP '2001-02-18 20:38:40');
       
        
         The ISO 8601 week-numbering year that the date
-        falls in (not applicable to intervals)
+        falls in
        
 
 
@@ -10256,7 +10256,7 @@ SELECT EXTRACT(ISOYEAR FROM DATE '2006-01-02');
       
        
         The Julian Date corresponding to the
-        date or timestamp (not applicable to intervals).  Timestamps
+        date or timestamp.  Timestamps
         that are not local midnight result in a fractional value.  See
          for more information.
        
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index cf3de80394..5d215d218c 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -10063,17 +10069,11 @@ SELECT EXTRACT(CENTURY FROM TIMESTAMP '2000-12-16 12:21:13');
 Result: 20
 SELECT EXTRACT(CENTURY FROM TIMESTAMP '2001-02-16 20:38:40');
 Result: 21
+SELECT EXTRACT(CENTURY FROM DATE '0001-01-01 AD');
+Result: 1
+SELECT EXTRACT(CENTURY FROM DATE '0001-12-31 BC');
+Result: -1
 
-
-       
-        The first century starts at 0001-01-01 00:00:00 AD, although
-        they did not know it at the time. This definition applies to all
-        Gregorian calendar countries. There is no century number 0,
-        you go from -1 century to 1 century.
-
-        If you disagree with this, please write your complaint to:
-        Pope, Cathedral Saint-Peter of Roma, Vatican.
-       
       
      
 
В списке pgsql-bugs по дате отправления
От: Francisco Olarte
Дата:
От: PG Bug reporting form
Дата:
FAQ