Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Vladimir Rusinov <vrusinov(at)google(dot)com>
Cc: Euler Taveira <euler(at)timbira(dot)com(dot)br>, David Steele <david(at)pgmasters(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Cynthia Shang <cynthia(dot)shang(at)crunchydata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal
Date: 2017-01-12 18:29:44
Message-ID: 8cb05f7c-db6f-1d21-0b83-2fd9e623ee7f@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/12/17 10:12 AM, Tom Lane wrote:
> Yeah, I'm not terribly for the extension idea. Robert cited the precedent
> of contrib/tsearch2, but I think the history of that is a good argument
> against this: tsearch2 is still there 9 years later and there's no
> indication that we'll ever get rid of it. We can let things rot
> indefinitely in core too. If we do ever agree to get rid of the aliases,
> stripping them out of pg_proc.h will not be any harder than removing
> a contrib directory would be.

Is there any burden to carrying tsearch2 around? Have we formally marked
it as deprecated?

The way I see it, either one person can spend an hour or whatever
creating an extension once, or every postgres install that's using any
of these functions now has yet another hurdle to upgrading.

If PGXN was better supported by the community maybe the answer would be
to just throw an extension up there. But that's certainly not the case.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-01-12 18:35:19 Re: WARM and indirect indexes
Previous Message Tom Lane 2017-01-12 18:25:43 Re: BUG: pg_stat_statements query normalization issues with combined queries