Re: [pgadmin-hackers] select inside transactions
Magnus Hagander wrote: I had to revert the patch on pgSetBase.cpp (Rev4986) because to handle the very special case of selects inside transactions when executed in a single step (I'd recommend to execute them step by step) the standard case of a query returning no data (e.g. drop table foo) didn't return messages any more. Yikes. I guess my disclaimer was well placed ;-) Did you just revert it, or did you figure out a proper way of doing it? Just reverted. Currently I don't see a proper way to implement it, unless multiple output panes (as in isqlw) are implemented. Bummer. I had that feeling - it seemed to easy :-( You could try to store the last result (for later returning), and drop it if a newer is detected. Please take care that return code of *all* commands are reported. Regards, Andreas ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers] select inside transactions
> >>I had to revert the patch on pgSetBase.cpp (Rev4986) > because to handle > >>the very special case of selects inside transactions when > executed in > >>a single step (I'd recommend to execute them step by step) the > >>standard case of a query returning no data (e.g. drop table foo) > >>didn't return messages any more. > > > > > > Yikes. I guess my disclaimer was well placed ;-) > > > > Did you just revert it, or did you figure out a proper way > of doing it? > > Just reverted. Currently I don't see a proper way to implement it, > unless multiple output panes (as in isqlw) are implemented. Bummer. I had that feeling - it seemed to easy :-( //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] select inside transactions
Magnus Hagander wrote: I had to revert the patch on pgSetBase.cpp (Rev4986) because to handle the very special case of selects inside transactions when executed in a single step (I'd recommend to execute them step by step) the standard case of a query returning no data (e.g. drop table foo) didn't return messages any more. Yikes. I guess my disclaimer was well placed ;-) Did you just revert it, or did you figure out a proper way of doing it? Just reverted. Currently I don't see a proper way to implement it, unless multiple output panes (as in isqlw) are implemented. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] select inside transactions
> I had to revert the patch on pgSetBase.cpp (Rev4986) because > to handle the very special case of selects inside > transactions when executed in a single step (I'd recommend to > execute them step by step) the standard case of a query > returning no data (e.g. drop table foo) didn't return > messages any more. Yikes. I guess my disclaimer was well placed ;-) Did you just revert it, or did you figure out a proper way of doing it? //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[pgadmin-hackers] select inside transactions
I had to revert the patch on pgSetBase.cpp (Rev4986) because to handle the very special case of selects inside transactions when executed in a single step (I'd recommend to execute them step by step) the standard case of a query returning no data (e.g. drop table foo) didn't return messages any more. Regards, Andreas ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
