> On 5 Mar 2020, at 21:52, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Having code which is untested and not excercised by developers (or users, if
>> my
>> assumption holds), yet being reachable by SQL, runs the risk of introducing
>> subtle bugs. Is there a usecase for keeping it, or ca
Daniel Gustafsson writes:
> When poking around here I realized that defGetStringList was also left unused.
> It was added with the logical decoding code but the single callsite has since
> been removed. As it's published in a header we might not want to remove it,
> but I figured I'd bring it up
Daniel Gustafsson writes:
> Having code which is untested and not excercised by developers (or users, if
> my
> assumption holds), yet being reachable by SQL, runs the risk of introducing
> subtle bugs. Is there a usecase for keeping it, or can/should it be removed
> in
> 14? That would still
Alvaro Herrera writes:
> On 2020-Mar-05, Tom Lane wrote:
>> As long as we're thinking of zapping code that is long past its sell-by
>> date, I propose getting rid of this stanza in indexcmds.c, which
>> basically causes CREATE INDEX to ignore certain opclass specifications:
> I agree, this should
> On 5 Mar 2020, at 19:36, Alvaro Herrera wrote:
>
> On 2020-Mar-05, Tom Lane wrote:
>
>> As long as we're thinking of zapping code that is long past its sell-by
>> date, I propose getting rid of this stanza in indexcmds.c, which
>> basically causes CREATE INDEX to ignore certain opclass specifi
On 2020-Mar-05, Tom Lane wrote:
> As long as we're thinking of zapping code that is long past its sell-by
> date, I propose getting rid of this stanza in indexcmds.c, which
> basically causes CREATE INDEX to ignore certain opclass specifications:
I agree, this should be fine to remove.
> Elsewhe
On 05/03/2020 16:33, Tom Lane wrote:
> Elsewhere in indexcmds.c, there's this:
>
> /*
> * Hack to provide more-or-less-transparent updating of old RTREE
> * indexes to GiST: if RTREE is requested and not found, use GIST.
> */
> if (strcmp(accessMethodName
Daniel Gustafsson writes:
> On 5 Mar 2020, at 15:42, Tom Lane wrote:
>> +1 --- I think this fits in well with my nearby proposal to remove
>> OPAQUE, which is also only relevant for pre-7.3 dumps. Let's just
>> nuke that stuff.
> Sounds good. I was opting for 14 to not violate the no new patche
> On 5 Mar 2020, at 15:42, Tom Lane wrote:
>
> Alvaro Herrera writes:
>>> On 2020-Mar-05, Daniel Gustafsson wrote:
>>> While looking at the tg_updatedcols patch I happened to notice that we still
>>> support pre-7.3 constraint triggers by converting them on the fly. AFAICT
>>> this
>>> require
On 3/5/20 9:42 AM, Tom Lane wrote:
Alvaro Herrera writes:
On 2020-Mar-05, Daniel Gustafsson wrote:
While looking at the tg_updatedcols patch I happened to notice that we still
support pre-7.3 constraint triggers by converting them on the fly. AFAICT this
requires a pre-7.3 dump to hit.
I k
Alvaro Herrera writes:
> On 2020-Mar-05, Daniel Gustafsson wrote:
>> While looking at the tg_updatedcols patch I happened to notice that we still
>> support pre-7.3 constraint triggers by converting them on the fly. AFAICT
>> this
>> requires a pre-7.3 dump to hit.
> I know it's a late in the c
On 2020-Mar-05, Daniel Gustafsson wrote:
> While looking at the tg_updatedcols patch I happened to notice that we still
> support pre-7.3 constraint triggers by converting them on the fly. AFAICT
> this
> requires a pre-7.3 dump to hit.
>
> This was added in late 2007 in a2899ebdc28080eab0f4bb0
While looking at the tg_updatedcols patch I happened to notice that we still
support pre-7.3 constraint triggers by converting them on the fly. AFAICT this
requires a pre-7.3 dump to hit.
This was added in late 2007 in a2899ebdc28080eab0f4bb0b8a5f30aa7bb31a89 due to
a report from the field, but I
13 matches
Mail list logo
