Re: cached plan must not change result type

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Jan Bilek <jan(dot)bilek(at)eftlab(dot)com(dot)au>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: cached plan must not change result type
Date: 2018-03-07 23:21:35
Message-ID: CAKFQuwYMDbB9FJJAACDKoxzeNqtL5wAz=9Oiz3qQ604GtC7Q7A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Mar 7, 2018 at 4:06 PM, Jan Bilek <jan(dot)bilek(at)eftlab(dot)com(dot)au> wrote:

> I would like to ask, would you see this solution in general as fine, or is
> there any better way to achieve this? I particularly dislike the part when
> we are trying matching return string on "cached plan must not change result
> type" as error messages might change (e.g. situations using different
> locales), is there any way how to get around this e.g. with enumerator?
>

Source code says that the errcode being returned is "Feature Not Supported"
which seems unreasonably broad​, I'd probably stick with message text
parsing. If you have locale concerns you could just check for one of the
11 different translations that are presently provided. Or combine them,
checking for the error code value first (which probably would be rare
enough in production code to be usable) then fall back to the description.

David J.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Doug Gorley 2018-03-07 23:23:38 How to monitor logical replication initial sync?
Previous Message David G. Johnston 2018-03-07 23:13:29 Re: Prefixing schema name