Re: [BUGS] BUG #6572: The example of SPI_execute is bogus
2012-04-14 18:15 keltezéssel, Peter Eisentraut írta: On lör, 2012-04-14 at 08:23 -0400, Robert Haas wrote: On Sat, Apr 14, 2012 at 3:27 AM, Pavel Stehule wrote: It has a lot of sense. Without it, it's very difficult to do logical replication on a table with no primary key. (Whether or not people should create such tables in the first place is, of course, beside the point.) I am not against to functionality - I am against just to syntax DELETE FROM tab LIMIT x because is it ambiguous what means: DELETE FROM tab RETURNING * LIMIT x What's ambiguous about that? I suppose one could wonder whether the LIMIT applies to the deleting or just the returning. Ambigous only in this order. LIMIT x RETURNING * wouldn't be. -- -- Zoltán Böszörményi Cybertec Schönig& Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6572: The example of SPI_execute is bogus
2012/4/15 Boszormenyi Zoltan : > 2012-04-14 18:15 keltezéssel, Peter Eisentraut írta: > >> On lör, 2012-04-14 at 08:23 -0400, Robert Haas wrote: >>> >>> On Sat, Apr 14, 2012 at 3:27 AM, Pavel Stehule >>> wrote: > > It has a lot of sense. Without it, it's very difficult to do logical > replication on a table with no primary key. > > (Whether or not people should create such tables in the first place > is, of course, beside the point.) I am not against to functionality - I am against just to syntax DELETE FROM tab LIMIT x because is it ambiguous what means: DELETE FROM tab RETURNING * LIMIT x >>> >>> What's ambiguous about that? >> >> I suppose one could wonder whether the LIMIT applies to the deleting or >> just the returning. > > > Ambigous only in this order. LIMIT x RETURNING * wouldn't be. but theoretically you can has two LIMIT clauses in one SQL statements DELETE FROM tab LIMIT n RETURNING * LIMIT m without updatable CTE it is probably only one solution, but because we have UCTE, then we don't need this construct. Regards Pavel > > -- > -- > Zoltán Böszörményi > Cybertec Schönig& Schönig GmbH > Gröhrmühlgasse 26 > A-2700 Wiener Neustadt, Austria > Web: http://www.postgresql-support.de > http://www.postgresql.at/ > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6572: The example of SPI_execute is bogus
Robert Haas writes: > On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada wrote: >> On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane wrote: >>> Given the lack of complaints since 9.0, maybe we should not fix this >>> but just redefine the new behavior as being correct? But it seems >>> mighty inconsistent that the tuple limit would apply if you have >>> RETURNING but not when you don't. In any case, the ramifications >>> are wider than one example in the SPI docs. >> To be honest, I was surprised when I found tcount parameter is said to >> be applied to even INSERT. I believe people think that parameter is >> to limit memory consumption when returning tuples thus it'd be applied >> for only SELECT or DML with RETURNING. So I'm +1 for non-fix but >> redefine the behavior. Who wants to limit the number of rows >> processed inside the backend, from SPI? > Yeah. Okay, apparently nobody cares about RETURNING behaving differently from non-RETURNING, so the consensus is to redefine the current behavior as correct. That means what we need is to go through the docs and see what places need to be updated (and, I guess, back-patch the changes to 9.0). I will get to this if nobody else does, but not right away. > 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. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
