Re: Partitions not Working as Expected

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: sthomas(at)optionshouse(dot)com
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dave Johansen <davejohansen(at)gmail(dot)com>, bricklen <bricklen(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Partitions not Working as Expected
Date: 2013-06-27 19:49:26
Message-ID: 51CC9746.5060804@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


On 06/27/2013 03:14 PM, Shaun Thomas wrote:
> On 06/27/2013 01:42 PM, Tom Lane wrote:
>
>> That will break things: CURRENT_DATE will then be equivalent to just
>> writing today's date as a literal.
>
> Interesting. I tested it by creating a view and a table with a
> default, and it always seems to get translated to:
>
> ('now'::text)::date
>
> But I'll take your explanation at face value, since that doesn't imply
> what the output would be. What's interesting is that EnterpriseDB has
> their own pg_catalog.current_date function that gets called by the
> CURRENT_DATE keyword. So unlike in vanilla PG, I could mark just the
> current_date function as immutable without affecting a lot of other
> internals.
>
> On EDB, this actually works:
>
> UPDATE pg_proc
> SET provolatile = 'i'
> WHERE proname = 'current_date';

But that's a lie, surely. If it breaks you have nobody to blame but
yourself. There's a reason EDB haven't marked their function immutable -
it's not.

cheers

andrew

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Shaun Thomas 2013-06-27 19:55:44 Re: Partitions not Working as Expected
Previous Message Shaun Thomas 2013-06-27 19:17:40 Re: Partitions not Working as Expected