BUG #6761: unexpected behaviour of 'now'::timestamp - Mailing list pgsql-bugs

From bert@brothom.nl
Subject BUG #6761: unexpected behaviour of 'now'::timestamp
Date
Msg-id E1Su15J-0001Oj-Ja@wrigleys.postgresql.org
Whole thread Raw
Responses Re: BUG #6761: unexpected behaviour of 'now'::timestamp  (Pavel Stehule <pavel.stehule@gmail.com>)
List 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 by date:

Previous
From: jez.wain@bull.net
Date:
Subject: BUG #6759: configure script fails to detect xlc compiler version
Next
From: ghazel@gmail.com
Date:
Subject: BUG #6756: primary_conninfo is ignored if restore_command is set..