From: | Nikolay Shaplov <dhyan(at)nataraj(dot)su> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Subject: | [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist |
Date: | 2018-01-17 20:50:04 |
Message-ID: | 3413542.LWpeoxCNq5@x200m |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi!
This patch is part of a bigger patch I've offered before
https://www.postgresql.org/message-id/flat/2146419(dot)veIEZdk4E4(at)x200m#2146419(dot)veIEZdk4E4@x200m
as we agreed I am trying to commit it by smaller bits
This patch raises error if user tries o set or change toast.* option for a
table that does not have a TOST relation.
I believe it is the only right thing to do, as now if you set toast reloption
for table that does not have TOAST table, the value of this option will be
lost without any warning. You will not get it back with pg_dump, it will not
be effective when you add varlen attributes to the table later.
So you offer DB some value to store, it accepts it without errors, and
immediately loses it. I would consider it a bad behavior.
I also think that we should not change this error to warning, as toast.*
options are usually used by very experienced users for precised DB tunning. I
hardly expect them to do TOAST tuning for tables without TOAST relations. So
chances to get problem with existing SQL code are minimal.
So I would suggest to throw an error in this case.
Possible flaws: I tied to write error messages according to guide lines. But I
suppose it is still not prefect enough as I am not so good with English. May
be somebody who knows the language well, can make it better.
--
Do code for fun.
Attachment | Content-Type | Size |
---|---|---|
no-toast-no-toast-options.diff | text/x-patch | 11.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-01-17 21:00:16 | Re: PostgreSQL crashes with SIGSEGV |
Previous Message | Peter Geoghegan | 2018-01-17 20:41:13 | Re: PostgreSQL crashes with SIGSEGV |