If people feel that backwards compatibiliy is important I would suggest
it be done in the following way:
A new connection parameter named 'compatible' be defined whose default
value is 7.2 (i.e new functionality). But you could set compatible=7.1
to revert back to the old functionality. (This is how Oracle deals with
similar issues in its code base). This parameter could then be set
either in the JDBC URL (i.e.
jdbc:postgresql://localhost:5432:template1?compatible=7.1) or passed
explicily in the connect() method.
thanks,
--Barry
Tom Lane wrote:
> Barry Lind <[EMAIL PROTECTED]> writes:
>
>>This is what I think needs to be done wrt large objects and binary data
>>support ...
>>[ much snipped ]
>>As you can probably guess I don't like the current implementation of
>>large objects in postgresql
>>
>
> Yup, I got that ;-).
>
> While these seem like good changes in the long run, I'm concerned about
> breaking existing client apps wholesale. Is it feasible to have a
> backwards-compatibility mode? I wouldn't even insist that it be the
> default behavior --- but adding a one-line "set backwards-compatible
> mode" kind of call seems better than major rewrites, for apps that
> depend on the old behavior.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
>
>
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
