Sergey Shelukhin wrote
> Due to presence of a large number of historical installations {doing such
> and such} is not viable.
Yeah, PostgreSQL faces this same issue....
If you intend to stay here long, and we hope you do (welcome by the way), it
is customary to bottom-post on these lists.
One other thought is that exception generation and handling is expensive.
It probably is a fair trade-off - since the ORM is already slow the added
overhead of the failing optimization query shouldn't be that noticeable.
Failure means either bad code or incorrect pre-conditions; both of which
should be explicitly checked and reported on. If those checks fail the
system can auto-configure to use the backup (ORM) channel instead of the
primary (optimized) channel.
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/not-aborting-transactions-on-failed-select-tp5770387p5770478.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
