Re: Proposal: PL/PgSQL strict_mode
От | Marko Tiikkaja |
---|---|
Тема | Re: Proposal: PL/PgSQL strict_mode |
Дата | |
Msg-id | 5234B342.6030009@joh.to обсуждение исходный текст |
Ответ на | Re: Proposal: PL/PgSQL strict_mode (chris travers <chris@2ndquadrant.com>) |
Список | pgsql-hackers |
(Oops, just realized I only replied to a part of your message. I'm blaming it on my lack of sleep.) On 14/09/2013 06:53, chris travers wrote: >> 2) If you're running in strict mode and you want to >> insert/update/delete more than one row, things get a bit uglier; a wCTE >> would work for some cases. If strict mode doesn't affect EXECUTE (see >> point 1 above), that could work too. Or maybe there could be a new >> command which runs a query, discards the results and ignores the number >> of rows processed. > > Yeah, I am worried about this one. I am concerned that if you can't disable on > a statement by statement basis, then you have a problem where you end up > removing the mode from the function and then it becomes a lot harder for > everyone maintaining the function to have a clear picture of what is going on. > I am further worried that hacked ugly code ways around it will introduce plenty > of other maintenance pain points that will be worse than what you are solving. I completely agree. If you can't turn the option on globally, you're bound to hit problems at some point. My thinking currently is that this mode would require adding a new type of statement (I'd call it PERFORM, but I know that one's been taken, so please don't get hung up on that): PERFORM UPDATE foo SET ..; or PERFORM SELECT foo(id) FROM ..; This statement would allow you to run any statement in strict mode without hitting the "more than one row processed" error message. >> I'll be adding this to the open commitfest in hopes of getting some >> feedback on this idea (I'm prepared to hear a lot of "you're crazy!"), >> but feel free to comment away any time you please. > > Well, I don't know if my feedback above is helpful, but there it is ;-) Thanks for your input! Regards, Marko Tiikkaja
В списке pgsql-hackers по дате отправления: