Re: PSQL commands: \quit_if, \quit_unless

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, PostgreSQL <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PSQL commands: \quit_if, \quit_unless
Date: 2016-12-02 02:01:05
Message-ID: 26981.1480644065@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Given the precedent in pgbench (cf.
> 878fdcb843e087cc1cdeadc987d6ef55202ddd04), I think it requires an
> amazing level of optimism to suppose we won't eventually end up with a
> full-blown expression language here. I would suggest designing one
> from the beginning and getting it over with. Even if you manage to
> hold the line and exclude it from whatever gets committed initially,
> somebody's going to propose it 2 years from now. And again 4 years
> from now. And again 2 years after that.

The other problem with not thinking about that general case is that
people will keep on proposing little bitty features that nibble at
the problem but may or may not be compatible with a general solution.
To the extent that such patches get accepted, we'll be forced into
either backwards-compatibility breakage or sub-optimal solutions when
we do get to the point of wanting a general answer. I'd much rather
start with a generalized design and then implement it piece by piece.

(This is more or less the same point as my nearby stand against localized
hacking of backslash parsing rules.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-12-02 02:02:53 Re: s/xlog/wal/ in tools and function names?
Previous Message Magnus Hagander 2016-12-02 01:58:23 Re: Proposal for changes to recovery.conf API