Re: ERROR: functions in index expression must be marked IMMUTABLE

From: "Sven R(dot) Kunze" <srkunze(at)mail(dot)de>
To: Geoff Winkless <pgsqladmin(at)geoff(dot)dj>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: ERROR: functions in index expression must be marked IMMUTABLE
Date: 2017-03-03 11:44:27
Message-ID: 4e4d464d-efa7-f004-4070-31457dfead7e@mail.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 03.03.2017 11:43, Geoff Winkless wrote:
> One alternative would be to make to_date accept all language variants
> of months simultaneously. A quick search of google suggests that there
> aren't any overlaps between languages (ie where one language uses
> "Foo" for March and another uses "Foo" for May), although you would
> have to​ do some more intense research to be sure. As far as I can see
> there's no other reason why to_date would need to be marked as
> stable/volatile, is there?

I don't think so. It could be viable.

> On the down side I imagine it would involve some
> potentially-prohibitively-large lookup tables; it would also end up
> with a technical incompatibility in that what ANSI SQL would reject as
> not-a-date might be parsed as a date.

There is another issue: languages change (admittedly very slowly) but I
wouldn't want PostgreSQL to be incompatible with future generations.
Your performance argument weighs heavier, though.

> I'm not in a position to judge if either of those would be acceptable.

Do you think I should post to pgsql-hackers?

Sven

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Rui Pacheco 2017-03-03 11:51:44 PortalSuspended
Previous Message Geoff Winkless 2017-03-03 10:43:32 Re: ERROR: functions in index expression must be marked IMMUTABLE