BUG #6761: unexpected behaviour of 'now'::timestamp

Поиск
Список
Период
Сортировка
От bert@brothom.nl
Тема BUG #6761: unexpected behaviour of 'now'::timestamp
Дата
Msg-id E1Su15J-0001Oj-Ja@wrigleys.postgresql.org
обсуждение исходный текст
Ответы Re: BUG #6761: unexpected behaviour of 'now'::timestamp  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-bugs
The following bug has been logged on the website:

Bug reference:      6761
Logged by:          Bert Thomas
Email address:      bert@brothom.nl
PostgreSQL version: 9.1.3
Operating system:   Linux
Description:=20=20=20=20=20=20=20=20

Hi,

To reproduce what I mean, consider this function:

CREATE FUNCTION testbug() RETURNS character varying
    LANGUAGE plpgsql
    AS $$declare
  l_ts timestamp(0);

begin
  l_ts :=3D 'now'::timestamp(0);
  return l_ts::varchar;
end
$$;

If a program invokes this function multiple times on a single connection,
only the first time the correct date and time is produced. All other
invocations return the exact same value as the first invocation.

Changing the function to this fixes the problem:

CREATE FUNCTION testbug() RETURNS character varying
    LANGUAGE plpgsql
    AS $$declare
  l_ts timestamp(0);
  l_nu varchar;

begin
  l_nu :=3D 'now';
  l_ts :=3D l_nu::timestamp(0);
  return l_ts::varchar;
end
$$;

Appearently the expression is re-evaluated every time in this case, whilst
in the first case it is only evaluated once as the constant 'now' could not
change obviously. I'm not sure if this is a bug or not, but at least it is
suprising behaviour. To me it looks like a bad form of optimization.

Kind regards,
Bert Thomas
BroThom

В списке pgsql-bugs по дате отправления:

Предыдущее
От: jez.wain@bull.net
Дата:
Сообщение: BUG #6759: configure script fails to detect xlc compiler version
Следующее
От: ghazel@gmail.com
Дата:
Сообщение: BUG #6756: primary_conninfo is ignored if restore_command is set..