This change relates only to SPI, meaning plpsql. It does not help libpq.
---
Ilja Golshtein wrote:
Hello!
According to Tom's message
http://archives.postgresql.org/pgsql-general/2005-06/msg00476.php
we have the stuff
Hi!
This change relates only to SPI, meaning plpsql. It does not help libpq.
Thanks for response.
I see.
Any hope it would be possible
to calculate number of rows inserted
in newly created table via
CREATE .. AS SELECT?
--
Best regards
Ilja Golshtein
---(end of
Hello!
According to Tom's message
http://archives.postgresql.org/pgsql-general/2005-06/msg00476.php
we have the stuff supposed to return number of rows affected by
CREATE .. AS SELECT or SELECT ... INTO in 8.1 beta.
The patch is at place, though PQcmdTuples returns nothing. It's not
a big
Hi!
Done. Here is the patch (against CVS tip, but it should apply with
some fuzz in 8.0 or 7.4).
Is this patch about CREATE TEMP TABLE AS SELECT only,
or about SELECT INTO TEMP TABLE as well?
--
Best regards
Ilja Golshtein
---(end of
Ilja Golshtein wrote:
Hi!
Done. Here is the patch (against CVS tip, but it should apply with
some fuzz in 8.0 or 7.4).
Is this patch about CREATE TEMP TABLE AS SELECT only,
or about SELECT INTO TEMP TABLE as well?
It should handle both because internally they are the same.
--
Bruce
Alvaro Herrera [EMAIL PROTECTED] writes:
On Tue, May 31, 2005 at 03:43:56PM -0400, Tom Lane wrote:
OK, next question: is this a bug fix we should back-patch into 7.4,
or just change it in HEAD?
I guess apply only in HEAD, and provide the patch for MLikharev so he
can solve his immediate
Thanks.
Alvaro Herrera [EMAIL PROTECTED] writes:
On Tue, May 31, 2005 at 03:43:56PM -0400, Tom Lane wrote:
OK, next question: is this a bug fix we should back-patch into 7.4,
or just change it in HEAD?
I guess apply only in HEAD, and provide the patch for MLikharev so he
can solve his
On Tue, May 31, 2005 at 01:03:30AM -0400, Tom Lane wrote:
So the initial evidence is that this was not an intentional change.
Do we want to revert it? The behavior has been in the field now for
more than a full release cycle --- all 7.4.* releases behave this way
--- so one could argue that
Alvaro Herrera [EMAIL PROTECTED] writes:
On Tue, May 31, 2005 at 01:03:30AM -0400, Tom Lane wrote:
So the initial evidence is that this was not an intentional change.
Do we want to revert it? The behavior has been in the field now for
more than a full release cycle --- all 7.4.* releases
On Tue, May 31, 2005 at 03:43:56PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Tue, May 31, 2005 at 01:03:30AM -0400, Tom Lane wrote:
So the initial evidence is that this was not an intentional change.
Do we want to revert it? The behavior has been in the field now
On Tue, 2005-05-31 at 15:43 -0400, Tom Lane wrote:
OK, next question: is this a bug fix we should back-patch into 7.4,
or just change it in HEAD?
I agree with Alvaro: fix it in HEAD, but don't backport the change to
8.0 or 7.4.
-Neil
---(end of
Can someone in the community comment on this question? I don't know the
answer.
---
[EMAIL PROTECTED] wrote:
Hi, I was asking this question some time ago and was under impression
that this will be fixed in 8.x. In
Bruce Momjian pgman@candle.pha.pa.us writes:
Can someone in the community comment on this question? I don't know the
answer.
I think it could be changed back without much work, but I have a feeling
that we'd deliberately decided on the change of behavior. Can anyone
recall a prior discussion,
Hello,
I was not able to find any traces from the previous discussion trend,
but I believe that finished when I replaced GET DIAGNOSTIC with SELECT COUNT().
Perfectly fine workaround, but more I look at that more I see why GET
DIAGNOSTIC was so convenient not to mentioned that SELECT COUNT()
I found a discussion of this issue from December, 2004:
http://archives.postgresql.org/pgsql-general/2004-12/msg00070.php
The discussion trailed off with the idea that because no rows were
returned to the function, the row_count should be zero, but then there
was some discussion that
Bruce Momjian pgman@candle.pha.pa.us writes:
I found a discussion of this issue from December, 2004:
http://archives.postgresql.org/pgsql-general/2004-12/msg00070.php
That was the same complainant ;-)
I dug through the CVS history and determined that the behavior changed
at spi.c rev
Hi,
I was asking this question some time ago and was under impression that this
will be fixed in 8.x. In general problem is, CREATE TEMP TABLE AS SELECT does
not report any rows to the engine, seems like, so GET DIAGNOSTICS ROW_COUNT
after the statement returns 0 as well as FOUND false. This
17 matches
Mail list logo
