Re: [HACKERS] Variable substitution in psql backtick expansion
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Variable substitution in psql backtick expansion |
Дата | |
Msg-id | CA+TgmobXCcEM7uB8_g+tKfB-1gvEyp+Qmmre9bcXU9mgpmW38Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Variable substitution in psql backtick expansion (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Variable substitution in psql backtick expansion
|
Список | pgsql-hackers |
On Fri, Aug 25, 2017 at 6:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > My question was more about how much of a use-case there is for these > values if there's no expression language yet. On reflection though, > you can use either expr-in-backticks or a server query to make > comparisons, so there's at least some use-case for the numeric > versions today. I'm still not sure that there's any use case for the > string versions ("9.6.4" etc). If somebody's doing comparisons, they probably want the numeric version, but somebody might want to print the string version in an error message e.g. \if <test involving VERSION_NUM> \echo this thing doesn't work on :VERSION_NAME \quit \endif >> - Is it a good idea/practical to prevent the new variables from being >> modified by the user? > > We haven't done that for existing informational variables, only control > variables that affect psql's behavior. I think we should continue that > policy for new informational variables. If we make them read-only, we > risk breaking scripts that are using those names for their own purposes. > If we don't make them read-only, we risk breaking scripts that are using > those names for their own purposes AND expecting them to provide the > built-in values. The latter risk seems strictly smaller, probably much > smaller. OK, got it. >> - I think Pavel's upthread suggestion of prefixing the client >> variables with "client" to match the way the server variables are >> named is a good idea. > > Well, the issue is the precedent of VERSION for the long-form string > spelling of psql's version. But I agree that's not a very nice > precedent. No strong opinion here. Hmm, well I think that's probably a pretty good reason to stick with the names in the proposed patch. VERSION seems like it was shortsighted, but I think we're probably best off being consistent with the precedent at this point. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: