Re: PSQL commands: \quit_if, \quit_unless - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PSQL commands: \quit_if, \quit_unless
Date
Msg-id 26981.1480644065@sss.pgh.pa.us
Whole thread Raw
In response to Re: PSQL commands: \quit_if, \quit_unless  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: PSQL commands: \quit_if, \quit_unless  (Corey Huinker <corey.huinker@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.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



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Proposal for changes to recovery.conf API
Next
From: Michael Paquier
Date:
Subject: Re: s/xlog/wal/ in tools and function names?