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

From Corey Huinker
Subject Re: PSQL commands: \quit_if, \quit_unless
Date
Msg-id CADkLM=dA46KCQpsB24HQzoZ_f2K26BWKNxye35vp5dcdBueWGw@mail.gmail.com
Whole thread
In response to Re: PSQL commands: \quit_if, \quit_unless  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PSQL commands: \quit_if, \quit_unless
Re: PSQL commands: \quit_if, \quit_unless
List pgsql-hackers

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 order for me to understand how high the bar has been set, can you (Robert/Tom mostly, but I welcome any responses) explain what you mean by "full-blown expression language"? What constructs must it include, etc?





pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: UNDO and in-place update
Next
From: Alvaro Herrera
Date:
Subject: Re: patch: function xmltable