Re: [BUGS] BUG #6572: The example of SPI_execute is bogus
| От | Robert Haas |
|---|---|
| Тема | Re: [BUGS] BUG #6572: The example of SPI_execute is bogus |
| Дата | |
| Msg-id | CA+TgmobbJZSLb1mKj3QwRjk1LmtS5uZsmycf_oZMaF4FXSdFtA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [BUGS] BUG #6572: The example of SPI_execute is bogus (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On Sun, Apr 15, 2012 at 12:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I think it would be a good idea for UPDATE and DELETE to expose >> a LIMIT option, but I can't really see the virtue in making that >> functionality available only through SPI. > > FWIW, I'm not excited about that. You can get well-defined behavior > today from a SELECT/LIMIT drawing from a writable CTE (namely, that > the UPDATE/DELETE runs to completion but you only see a subset of > its RETURNING result). LIMIT directly on the UPDATE/DELETE would be > ill-defined, unless perhaps you want to also invent a way of specifying > the order in which rows get selected for update; but I don't want to > go there. In the use cases I'm thinking of, it doesn't matter which row you decide to update or delete, only that you pick a single one. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: