From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
Cc: | Nikita Malakhov <hukutoc(at)gmail(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] ALTER TABLE ... SET STORAGE default |
Date: | 2022-11-05 17:45:59 |
Message-ID: | 2623256.1667670359@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Aleksander Alekseev <aleksander(at)timescale(dot)com> writes:
> Hi Nikita,
>> This seems a little bit confusing and thus very unfriendly for the user, because the actual meaning
>> of the same 'DEFAULT' option will be different for each data type, and to check storage mode user
>> has to query full table (or column) description.
>> I'd rather add a paragraph in documentation describing each data type default storage mode.
> I agree that "SET STORAGE default" syntax leaves much to be desired.
FWIW, I don't buy that argument at all. If you believe that then
you must also think that
INSERT INTO mytab VALUES (..., DEFAULT, ...);
is a poorly-designed feature because you have to go consult the table
definition to find out what will be inserted. (Well, maybe you do
think that, but the SQL committee won't agree with you ;-)) So I don't
see any problem with DEFAULT representing a data-type-specific default
in this situation.
> Personally I would prefer "RESET STORAGE" and "RESET COMPRESSION".
Perhaps, but what's done is done, and I agree that STORAGE had better
follow the existing precedent.
I've not read the patch in any detail, but I don't see a problem
with the design.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-11-05 18:22:56 | Re: pg_reload_conf() synchronously |
Previous Message | Corey Huinker | 2022-11-05 17:39:09 | Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands |