On August 22, 2014 8:33:57 PM CEST, Bruce Momjian <bruce@momjian.us> wrote:
>On Fri, Aug 22, 2014 at 12:53:30PM -0400, Bruce Momjian wrote:
>> On Fri, Aug 22, 2014 at 10:27:02AM -0400, Robert Haas wrote:
>> > On Thu, Aug 21, 2014 at 7:17 PM, Bruce Momjian <bruce@momjian.us>
>wrote:
>> > > On Tue, Mar 18, 2014 at 09:11:46AM -0400, Robert Haas wrote:
>> > >> On Mon, Mar 17, 2014 at 10:27 PM, Michael Paquier
>> > >> <michael.paquier@gmail.com> wrote:
>> > >> > On Tue, Mar 18, 2014 at 10:24 AM, Fabrízio de Royes Mello
>> > >> > <fabriziomello@gmail.com> wrote:
>> > >> >>
>> > >> >> On Thu, Mar 13, 2014 at 10:22 AM, Robert Haas
><robertmhaas@gmail.com> wrote:
>> > >> >>> Well, it's fairly harmless, but it might not be a bad idea
>to tighten that
>> > >> >>> up.
>> > >> >> The attached patch tighten that up.
>> > >> > Hm... It might be interesting to include it in 9.4 IMO,
>somewhat
>> > >> > grouping with what has been done in a6542a4 for SET and ABORT.
>> > >>
>> > >> Meh. There will always be another thing we could squeeze in; I
>don't
>> > >> think this is particularly urgent, and it's late to the party.
>> > >
>> > > Do we want this patch for 9.5? It throws an error for invalid
>reloption
>> > > specifications.
>> >
>> > Fine with me. But I have a vague recollection of seeing pg_upgrade
>> > doing this on purpose to create TOAST tables or something... am I
>> > misremembering?
>>
>> Yes, you remember well. I will have to find a different way for
>> pg_upgrade to call a no-op ALTER TABLE, which is fine.
>
>Looking at the ALTER TABLE options, I am going to put this check in a
>!IsBinaryUpgrade block so pg_upgrade can still use it?
Why not simply not do anything? This doesn't prevent any bugs and requiring pg-upgrade specific checks in there seems
absurd.Also somebody might use it for similar purposes.
---
Please excuse brevity and formatting - I am writing this on my mobile phone.
