Re: Client-requested cast mode to emulate Pg8.2 on v8.3 - Mailing list pgsql-general

From Anton Melser
Subject Re: Client-requested cast mode to emulate Pg8.2 on v8.3
Date
Msg-id 92d3a4950803210905n393fca5fj47b5cf2d9e00b1ea@mail.gmail.com
Whole thread Raw
In response to Re: Client-requested cast mode to emulate Pg8.2 on v8.3  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Client-requested cast mode to emulate Pg8.2 on v8.3
List pgsql-general
>  >  - Is there a way to turn it back to the old behaviour with a
>  >    warning going to the logs?
>
>
> No.
>
>
>  >  - Is there a way to get v8.2.x to warn on the dubious casts
>  >    so we can tighten the application side while on v8.2?
>
>
> Seems to me the easiest way would be to try it out on an 8.3
>  installation and exercise each query once. There may be a better way
>  but I don't know it...

Hi,
This seems like it is one of the most frustrating (for me) decisions
that has ever been made by the postgres developers...
My situation is the following :
I inherited an application based on a dead project (byline, and don't
even mention aplaws, it's about as alive a zombie from Resident
Evil... it moves, but it ain't alive!) and we currently use postgres
8.1. The performance sucks, and there are several things in 8.3 that
are very interesting, notably synchronous_commit, plus all the
perfermance goodies since 8.1. But it is COMPLETELY out of the
question to redo the db abstraction layer, and without these implicit
casts that is what will be needed. Is there REALLY no way to reenable
it?
I fully realise and respect the logic in doing this but not having a
fallback (even if it means recompiling from source) is painful!
Am I really stuck with pre-8.3?
Cheers
Anton

pgsql-general by date:

Previous
From: "Pavan Deolasee"
Date:
Subject: Re: Table size
Next
From: Tom Lane
Date:
Subject: Re: ecpg program getting stuck