Re: Patch for bug #17056 fast default on non-plain table

Andrew Dunstan writes: > On 6/17/21 1:45 PM, Tom Lane wrote: >> OK. One other point is that in HEAD, you only need the hunk that >> prevents atthasmissing from becoming incorrectly set. > Good point. Should I replace the relcache.c changes in HEAD with an > Assert? Or just skip them altogether?

Re: Patch for bug #17056 fast default on non-plain table

On 6/17/21 1:45 PM, Tom Lane wrote: > Andrew Dunstan writes: >> revised patch attached. > OK. One other point is that in HEAD, you only need the hunk that > prevents atthasmissing from becoming incorrectly set. The hacks > to cope with it being already wrong are only needed in the back > branc

Re: Patch for bug #17056 fast default on non-plain table

Andrew Dunstan writes: > revised patch attached. OK. One other point is that in HEAD, you only need the hunk that prevents atthasmissing from becoming incorrectly set. The hacks to cope with it being already wrong are only needed in the back branches. Since we already forced initdb for beta2,

Re: Patch for bug #17056 fast default on non-plain table

On 6/17/21 11:13 AM, Andrew Dunstan wrote: > On 6/17/21 11:05 AM, Tom Lane wrote: >> Andrew Dunstan writes: >>> Here's a patch I propose to apply to fix this bug (See >>>

Re: Patch for bug #17056 fast default on non-plain table

On 6/17/21 11:05 AM, Tom Lane wrote: > Andrew Dunstan writes: >> Here's a patch I propose to apply to fix this bug (See >> ) > If I'm reading the code correctly, your

Re: Patch for bug #17056 fast default on non-plain table

Andrew Dunstan writes: > Here's a patch I propose to apply to fix this bug (See > ) If I'm reading the code correctly, your change in RelationBuildTupleDesc is scribbli