On Sat, Jan 22, 2011 at 9:11 PM, Robert Haas robertmh...@gmail.com wrote:
It seems no one wants to put any further effort into this problem. Bummer.
Since no one has felt the need to dispute the above statement in the
last 6 days, it seems clear to mark this Returned with Feedback, which
I have
On Fri, Jan 28, 2011 at 21:04, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jan 22, 2011 at 9:11 PM, Robert Haas robertmh...@gmail.com wrote:
It seems no one wants to put any further effort into this problem. Bummer.
Since no one has felt the need to dispute the above statement in the
On Mon, Jan 17, 2011 at 2:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jan 17, 2011 at 2:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 17, 2011 at 9:41 AM, Peter Eisentraut pete...@gmx.net wrote:
Maybe instead of the proposed patch,
On fre, 2011-01-14 at 18:45 -0500, Robert Haas wrote:
On Fri, Jan 14, 2011 at 3:45 PM, Marti Raudsepp ma...@juffo.org
wrote:
There's a similar case with CREATE TABLE IF NOT EXISTS, maybe this
is
worth covering in an updated patch too?
And if I change that, people might expect the same
On Mon, Jan 17, 2011 at 9:41 AM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2011-01-14 at 18:45 -0500, Robert Haas wrote:
On Fri, Jan 14, 2011 at 3:45 PM, Marti Raudsepp ma...@juffo.org
wrote:
There's a similar case with CREATE TABLE IF NOT EXISTS, maybe this
is
worth covering in an
On mån, 2011-01-17 at 10:05 -0500, Robert Haas wrote:
On Mon, Jan 17, 2011 at 9:41 AM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2011-01-14 at 18:45 -0500, Robert Haas wrote:
On Fri, Jan 14, 2011 at 3:45 PM, Marti Raudsepp ma...@juffo.org
wrote:
There's a similar case with CREATE
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 17, 2011 at 9:41 AM, Peter Eisentraut pete...@gmx.net wrote:
Maybe instead of the proposed patch, a notice could be added:
NOTICE: existing object was replaced
Well, that would eliminate the backward-compatibility hazard, pretty
much, but
On Mon, Jan 17, 2011 at 09:23:07PM +0200, Peter Eisentraut wrote:
On mån, 2011-01-17 at 10:05 -0500, Robert Haas wrote:
On Mon, Jan 17, 2011 at 9:41 AM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2011-01-14 at 18:45 -0500, Robert Haas wrote:
On Fri, Jan 14, 2011 at 3:45 PM, Marti
On Mon, Jan 17, 2011 at 2:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 17, 2011 at 9:41 AM, Peter Eisentraut pete...@gmx.net wrote:
Maybe instead of the proposed patch, a notice could be added:
NOTICE: existing object was replaced
Well, that
Here's an updated patch that reports command status back to
ProcessUtility via 'bool' return value.
I was a bit unsure about using bool return values because it's not
immediately obvious what true or false refer to, but defining a
new enum seemed like overkill, so I went with bool anyway. Any
2011/1/13 KaiGai Kohei kai...@ak.jp.nec.com:
I tried to pick up this patch to review.
It seems to me fine, enough simple and works as explained in the
implementation level, apart from reasonability of this feature.
(Tom was not 100% agree with this feature 1.5month ago.)
Did you check
Excerpts from Robert Haas's message of vie ene 14 08:40:07 -0300 2011:
Also, I don't really like the way this spreads knowledge of the
completionTag out all over the backend. I think it would be better to
follow the existing model used by the COPY and COMMIT commands,
whereby the return
On Fri, Jan 14, 2011 at 9:24 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of vie ene 14 08:40:07 -0300 2011:
Also, I don't really like the way this spreads knowledge of the
completionTag out all over the backend. I think it would be better to
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of vie ene 14 08:40:07 -0300 2011:
Also, I don't really like the way this spreads knowledge of the
completionTag out all over the backend. I think it would be better to
follow the existing model used by the
On Fri, 2011-01-14 at 12:07 -0500, Tom Lane wrote:
I thought we were going to reject the patch outright anyway. The
compatibility consequences of changing command tags are not worth the
benefit, independently of how ugly the backend-side code may or may
not be.
+1
--
Simon Riggs
On Fri, Jan 14, 2011 at 12:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of vie ene 14 08:40:07 -0300 2011:
Also, I don't really like the way this spreads knowledge of the
completionTag out all over the backend.
Robert Haas robertmh...@gmail.com writes:
If we're going to reject this patch on backwards-compatibility
grounds, we need to make an argument that the backward-compatibility
hazards are a real concern. So, again, has anyone complained about
the changes we made in this area in 9.0?
That 9.0
On Fri, Jan 14, 2011 at 1:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
If we're going to reject this patch on backwards-compatibility
grounds, we need to make an argument that the backward-compatibility
hazards are a real concern. So, again, has anyone
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 14, 2011 at 1:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That 9.0 change was far less invasive than this: it only added a count
field to SELECT and CTAS result tags. Quite aside from the fact that
the tag name stayed the same, in the SELECT
On Fri, Jan 14, 2011 at 2:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 14, 2011 at 1:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That 9.0 change was far less invasive than this: it only added a count
field to SELECT and CTAS result tags. Quite
Thanks for reviewing!
On Fri, Jan 14, 2011 at 13:40, Robert Haas robertmh...@gmail.com wrote:
Did you check whether this updated the code for 100% of the object
types where this could apply?
I walked through all the CREATE statements in the documentation and
these four seem to be the only ones
On Fri, Jan 14, 2011 at 3:45 PM, Marti Raudsepp ma...@juffo.org wrote:
There's a similar case with CREATE TABLE IF NOT EXISTS, maybe this is
worth covering in an updated patch too?
And if I change that, people might expect the same from DROP X IF EXISTS too?
It's far less clear what you'd
I tried to pick up this patch to review.
It seems to me fine, enough simple and works as explained in the
implementation level, apart from reasonability of this feature.
(Tom was not 100% agree with this feature 1.5month ago.)
I'm not certain whether the current regression test should be
Hi list,
Often enough when developing PostgreSQL views and functions, I have
pasted the CREATE OR REPLACE commands into the wrong window/shell and
ran them there without realizing that I'm creating a function in the
wrong database, instead of replacing. Currently psql does not provide
any
Marti Raudsepp ma...@juffo.org writes:
This patch returns command tag CREATE X or REPLACE X for
LANGAUGE/VIEW/RULE/FUNCTION. This is done by passing completionTag to
from ProcessUtility to more functions, and adding a 'bool *didUpdate'
argument to some lower-level functions. I'm not sure if
On Sun, Nov 28, 2010 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Marti Raudsepp ma...@juffo.org writes:
This patch returns command tag CREATE X or REPLACE X for
LANGAUGE/VIEW/RULE/FUNCTION. This is done by passing completionTag to
from ProcessUtility to more functions, and adding a 'bool
Robert Haas robertmh...@gmail.com writes:
I think more expessive command tags are in general a good thing. The
idea that this particular change would be useful primarily for humans
examining the psql output seems a bit weak to me, but I can easily see
it being useful for programs. Right now
27 matches
Mail list logo
