At 04:01 PM 4/25/02 -0300, Marc G. Fournier wrote:
> > 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 ...
I don't know about those programmers, but AFAIK when I shift from one DBMS
to another I expect weird things to happen, because the whole DBMS world is
filled with all sorts of "no standard" behaviour.
SET XXX doesn't even directly map to Oracle's stuff in the first place.
Since it looks different, I think the migrator shouldn't be surprised if it
works differently. They might expect it to work the same, but if it doesn't
they'll just go "OK yet another one of those".
What would be good are "RDBMS X to Postgresql" migration docs. I believe
there's already an Oracle to Postgresql migration document. So putting all
these things there and linking to them would be helpful.
---
I'm sorry if this has been discussed already:
There may be some SETs which operate on a different level of the
application. We may wish to clearly differentiate them from those that are
transactional and can operate in the domain of other SQL statements. Or put
those in config files and they never appear in SETs?
Coz some things should not be rolled back. So you guys might come up with a
different keyword for it.
e.g.
CONFIG: for non transactional stuff that can appear as SQL statements.
SET: for stuff that can be transactional.
Practical example: Does doing an enable seqscan affect OTHER db connections
and transactions as well? If it doesn't then yes it should be
transactional, whereas if does then it shouldn't bother being
transactional. And there could well be two cases operating in different
domains. e.g. CONFIG globalseqscan=0 and SET seqscan=0.
Regards,
Link.