Re: Fast default stuff versus pg_upgrade - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fast default stuff versus pg_upgrade
Date
Msg-id 21034.1529603451@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fast default stuff versus pg_upgrade  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2018-06-21 13:44:19 -0400, Tom Lane wrote:
>> Actually, now that I think about it, there is a concrete reason for the
>> historical pattern: it provides a cross-check that you did not fat-finger
>> the query, ie misspell the column alias vs the PQfnumber parameter.  This
>> gets more valuable the more per-version variants of the query there are.
>> With the way the attidentity code does it, it would just silently act as
>> though the column has its default value, which you might or might not
>> notice in cursory testing.  Getting visible bleats about column number -1
>> is much more likely to get your attention.

> To me that benefit is far smaller than the increased likelihood of
> screwing something up because you'd to touch pg_dump support for
> postgres versions one likely doesn't readily have available for testing.

I beg to differ: code that works "by omission" is just as likely to be
wrong.  Anyway, our solution for unmaintainable back branches has been
to drop support, cf where we got rid of the pre-8.0 queries awhile back.
One (admittedly small) problem with the "i_attidentity >= 0 ? ..." coding
is that it's not obvious when you can get rid of it because you dropped
the last old branch that needed it.  After that, it's just a hazard for
hiding mistakes.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Fast default stuff versus pg_upgrade
Next
From: Tom Lane
Date:
Subject: Re: Fast default stuff versus pg_upgrade