On Wed, Aug 29, 2012 at 01:13:51PM +, Rajeev rastogi wrote:
From: pgsql-bugs-ow...@postgresql.org [pgsql-bugs-ow...@postgresql.org] on
behalf of Bruce Momjian [br...@momjian.us]
Sent: Wednesday, August 29, 2012 8:46 AM
To: Tom Lane
Cc: Robert
Bruce Momjian br...@momjian.us writes:
Would someone make the doc change outlined above? Thanks.
Sorry, I'd nearly forgotten about this issue. Will see about fixing the
docs. (It looks like some of the comments in execMain.c could use work
too.)
regards, tom lane
--
On Thu, Jan 24, 2013 at 04:51:04PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Would someone make the doc change outlined above? Thanks.
Sorry, I'd nearly forgotten about this issue. Will see about fixing the
docs. (It looks like some of the comments in execMain.c could
From: pgsql-bugs-ow...@postgresql.org [pgsql-bugs-ow...@postgresql.org] on
behalf of Bruce Momjian [br...@momjian.us]
Sent: Wednesday, August 29, 2012 8:46 AM
To: Tom Lane
Cc: Robert Haas; Hitoshi Harada; pgsql-bugs@postgresql.org;
On Sun, Apr 15, 2012 at 12:29:39PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Given the lack of complaints since 9.0, maybe we
On Sun, Apr 15, 2012 at 12:29 PM, Tom Lane t...@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
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 Stehulepavel.steh...@gmail.com wrote:
It has a lot of sense. Without it, it's very difficult to do logical
replication on a table with no primary
2012/4/15 Boszormenyi Zoltan z...@cybertec.at:
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 Stehulepavel.steh...@gmail.com
wrote:
It has a lot of sense. Without it, it's very difficult to
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Given the lack of complaints since 9.0, maybe we should not fix this
but just redefine the new behavior as
2012/4/14 Robert Haas robertmh...@gmail.com:
On Fri, Apr 13, 2012 at 10:43 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Yeah. 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
On Sat, Apr 14, 2012 at 3:27 AM, Pavel Stehule pavel.steh...@gmail.com 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.)
On lör, 2012-04-14 at 08:23 -0400, Robert Haas wrote:
On Sat, Apr 14, 2012 at 3:27 AM, Pavel Stehule pavel.steh...@gmail.com
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
2012/4/14 Peter Eisentraut pete...@gmx.net:
On lör, 2012-04-14 at 08:23 -0400, Robert Haas wrote:
On Sat, Apr 14, 2012 at 3:27 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
It has a lot of sense. Without it, it's very difficult to do logical
replication on a table with no primary key.
On Sat, Apr 14, 2012 at 12:15 PM, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2012-04-14 at 08:23 -0400, Robert Haas wrote:
On Sat, Apr 14, 2012 at 3:27 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
It has a lot of sense. Without it, it's very difficult to do logical
replication on
On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
umi.tan...@gmail.com writes:
http://www.postgresql.org/docs/9.1/static/spi-spi-execute.html
===
SPI_execute(INSERT INTO foo SELECT * FROM bar, false,
Yeah. 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.
I don't agree - LIMIT after UPDATE or DELETE has no sense. Clean
solution should be based on using updateable CTE.
On Fri, Apr 13, 2012 at 10:43 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Yeah. 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.
I don't agree - LIMIT after UPDATE
On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
umi.tan...@gmail.com writes:
http://www.postgresql.org/docs/9.1/static/spi-spi-execute.html
===
SPI_execute(INSERT INTO foo SELECT * FROM bar, false, 5);
will allow at most 5 rows to be inserted into the table.
===
This
umi.tan...@gmail.com writes:
http://www.postgresql.org/docs/9.1/static/spi-spi-execute.html
===
SPI_execute(INSERT INTO foo SELECT * FROM bar, false, 5);
will allow at most 5 rows to be inserted into the table.
===
This seems not true unless I'm missing something.
Hmm ... that did work as
The following bug has been logged on the website:
Bug reference: 6572
Logged by: Hitoshi Harada
Email address: umi.tan...@gmail.com
PostgreSQL version: 9.1.3
Operating system: Any
Description:
http://www.postgresql.org/docs/9.1/static/spi-spi-execute.html
===
20 matches
Mail list logo
