Thread: CTAS command tags

CTAS command tags

From
Vik Fearing
Date:
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

From
Darafei "Komяpa" Praliaskouski
Date:
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

From
Andreas Karlsson
Date:
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

From
Tom Lane
Date:
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