Обсуждение: CTAS command tags

Поиск
Список
Период
Сортировка

CTAS command tags

От
Vik Fearing
Дата:
I was recently surprised by the following inconsistencies in returned
command tags for CTAS:


postgres=# create table a as select 123;
SELECT 1

postgres=# create table b as select 123 with data;
SELECT 1

postgres=# create table c as select 123 with no data;
CREATE TABLE AS


Shouldn't we make the first two tags (which are likely the same code
path; I haven't looked) the same as the third?  I can look into writing
the patch if desired.
-- 
Vik Fearing



Re: CTAS command tags

От
Darafei "Komяpa" Praliaskouski
Дата:
Having row count right away is very useful in CTAS in analytical and GIS usage scenarios. 

пт, 22 сту 2021, 16:14 карыстальнік Vik Fearing <vik@postgresfriends.org> напісаў:
I was recently surprised by the following inconsistencies in returned
command tags for CTAS:


postgres=# create table a as select 123;
SELECT 1

postgres=# create table b as select 123 with data;
SELECT 1

postgres=# create table c as select 123 with no data;
CREATE TABLE AS


Shouldn't we make the first two tags (which are likely the same code
path; I haven't looked) the same as the third?  I can look into writing
the patch if desired.
--
Vik Fearing


Re: CTAS command tags

От
Andreas Karlsson
Дата:
On 1/22/21 2:19 PM, Darafei "Komяpa" Praliaskouski wrote:
> Having row count right away is very useful in CTAS in analytical and GIS 
> usage scenarios.

I can see that, but would it not work if it was:

CREATE TABLE AS 1

Disclaimer: I have not looked at the code so maybe there is some good 
reason that would not work.

Andreas



Re: CTAS command tags

От
Tom Lane
Дата:
Andreas Karlsson <andreas@proxel.se> writes:
> On 1/22/21 2:19 PM, Darafei "Komяpa" Praliaskouski wrote:
>> Having row count right away is very useful in CTAS in analytical and GIS 
>> usage scenarios.

> I can see that, but would it not work if it was:
> CREATE TABLE AS 1

Changing the set of command tags that have counts attached would amount
to a wire-protocol break, because clients such as libpq know which ones
do.  So to standardize this as Vik wants, we'd have to make the WITH
NO DATA case return "SELECT 0" (not 1, surely).  That seems a little
weird.

I have a vague recollection that this has been discussed before,
though I lack the energy to go digging in the archives right now.

            regards, tom lane