Re: Vote totals for SET in aborted transaction
От | Marc G. Fournier |
---|---|
Тема | Re: Vote totals for SET in aborted transaction |
Дата | |
Msg-id | 20020425155938.O2368-100000@mail1.hub.org обсуждение исходный текст |
Ответ на | Re: Vote totals for SET in aborted transaction (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Vote totals for SET in aborted transaction
Re: Vote totals for SET in aborted transaction |
Список | pgsql-hackers |
On Thu, 25 Apr 2002, Bruce Momjian wrote: > Marc G. Fournier wrote: > > Okay, based on this, I'm pseudo-against ... I think, for reasons of > > reducing headaches for ppl posting, there should be some sort of 'SET > > oracle_quirks' operation that would allow for those with largish legacy > > apps trying to migrate over to do so without having to check for "odd" > > behaviours like this ... > > > > Or maybe "SET set_rollbacks = oracle"? with default being #1 as discussed > > Yes, I understand. However, seeing that we have gone 6 years with this > never being an issue, I think we should just shoot for #1 and keep open > to the idea of having a compatibility mode, and the possibility that #1 > may not fit for all SET variables and we may have to do some special > cases for those. > > My guess is that we should implement #1 and see what feedback we get in > 7.3. IMHO, it hasn't been thought out well enough to be implemented yet ... the options have been, but which to implement haven't ... right now, #1 is proposing to implement something that goes against what *at least* one of DBMS does ... so now you have programmers coming from that environment expecting one thing to happen, when a totally different thing results ...
В списке pgsql-hackers по дате отправления: