Re: CREATE TEMP TABLE AS SELECT/ GET DIAGNOSTICS ROW_COUNT

From: MLikharev(at)micropat(dot)com
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgman(at)candle(dot)pha(dot)pa(dot)us, pgsql-general(at)postgresql(dot)org
Subject: Re: CREATE TEMP TABLE AS SELECT/ GET DIAGNOSTICS ROW_COUNT
Date: 2005-05-30 21:27:19
Message-ID: 11d7ba11daf7.11daf711d7ba@micropat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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() is not a fastest
possible statement in PG.

Ideally what I would like are:
1. “Official” word whether that will be supported or not, ether way is fine,
but that will clear confusion for me and others.
2. Maybe some clause in docs clarifying behavior for the case

Best regards.

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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, or want to vote with or against MLikharev?

Note that the change is actually at the SPI level, and would affect
SPI_processed for all code using CREATE AS/SELECT INTO through SPI,
not only plpgsql.

regards, tom lane

Responses

Browse pgsql-general by date

  From Date Subject
Next Message bruce 2005-05-30 21:27:23 setting up default user
Previous Message Bruce Momjian 2005-05-30 21:08:23 Re: [HACKERS] Inherited constraints and search paths (was