On 3/1/20 10:09 PM, Amit Langote wrote:
> Hi Chris,
>
> On Mon, Mar 2, 2020 at 8:51 AM Chris Bandy <bandy.chris@gmail.com> wrote:
>> On 3/1/20 5:14 AM, Amit Kapila wrote:
>>> On Sun, Mar 1, 2020 at 10:10 AM Amit Langote <amitlangote09@gmail.com> wrote:
>>>>
>>>> There are couple more instances in src/backend/command/tablecmds.c
>>>> where partition constraint is checked:
>>>>
>>>> Maybe, better fix these too for completeness.
>>>
>>> Another thing we might need to see is which of these can be
>>> back-patched. We should also try to write the tests for cases we are
>>> changing even if we don't want to commit those.
>>
>> I don't have any opinion on back-patching. Existing tests pass. I wasn't
>> able to find another test that checks the constraint field of errors.
>> There's a little bit in the tests for psql, but that is about the the
>> \errverbose functionality rather than specific errors and their fields.
>
> Actually, it's not a bad idea to use \errverbose to test this.
>
I've added a second patch with tests that cover three of the five errors
touched by the first patch. Rather than \errverbose, I simply \set
VERBOSITY verbose. I could not find a way to exclude the location field
from the output, so those lines will be likely be out of date soon--if
not already.
I couldn't find a way to exercise the errors in tablecmds.c. Does anyone
know how to instigate a table rewrite that would violate partition
constraints? I tried:
ALTER TABLE pterr1 ALTER y TYPE bigint USING (y - 5);
ERROR: 42P16: cannot alter column "y" because it is part of the
partition key of relation "pterr1"
LOCATION: ATPrepAlterColumnType, tablecmds.c:10812
Thanks,
Chris
