mwolfМда.
Действительно интересно считает!!!


Это чтобы было еще интереснее ;)

template1=# select date_part('week', '01/03/2005'::date);
LOG: statement: select date_part('week', '01/03/2005'::date);
LOG: statement: select pg_catalog.date_part($1, cast($2 as timestamp without ti
me zone))
CONTEXT: SQL function "date_part" during startup
date_part
-----------
1
(1 row)

template1=# select date_part('week', '12/31/2004'::date);
LOG: statement: select date_part('week', '12/31/2004'::date);
LOG: statement: select pg_catalog.date_part($1, cast($2 as timestamp without ti
me zone))
CONTEXT: SQL function "date_part" during startup
date_part
-----------
53
(1 row)

template1=# select version()
template1-# ;
LOG: statement: select version()
;
version

--------------------------------------------------------------------------------
--------------------------
PostgreSQL 8.0.0beta2 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.2.3 (
mingw special 20030504-1)
(1 row)

template1=#

mwolf2 ilejn:
Ну и?
И как это спасёт отца русской демократии?


Я так понимаю, что тебя смутил вывод логов, но я всего
лишь хотел показать, что
в восьмой версии date_part('week',...) работает в полном
соответствии с интуитивными ожиданиями,
возвращая 1 для первого января 2005 года.

Спасет ли это отца русской демократии и одинаковы ли у нас
представления о правильной работе этой функции я не знаю.

Есть проверка за 03 января 2005 года и проверка за 31 декабря 2004 года. За 01 января 2005 года проверки я не вижу.
Кстати, эти же данные и у меня в версии 7.3.4.


Был неправ. Sorry.
1 января 53-я неделя и в восьмой версии тоже.