Hello Tom & Michaël,
I think this patch should be rejected.
+1 for rejection [...]
The noes have it!
Note that the motivation was really symmetric completion:
fabien=# \echo :VERSION_NAME
11devel
fabien=# \echo :VERSION_NUM
11
fabien=# \echo :VERSION
PostgreSQL 11devel on x86_64-
On Mon, Nov 13, 2017 at 5:21 AM, Tom Lane wrote:
> Pavel Stehule writes:
>> [ psql-server-version-2.patch ]
>
> I think this patch should be rejected. It adds no new functionality;
> you can get the string in question with "select version()". Moreover,
> you've been able to do that for lo these
Pavel Stehule writes:
> [ psql-server-version-2.patch ]
I think this patch should be rejected. It adds no new functionality;
you can get the string in question with "select version()". Moreover,
you've been able to do that for lo these many years. Any application
that tried to depend on this n
Hi
I am sending a review of last patch psql-server-version-1.patch.gz
This patch is trivial - the most big problem is choosing correct name for
GUC. I am thinking so server_version_raw is acceptable.
I had to fix doc - see attached updated patch
All tests passed.
I'll mark this patch as ready
Hello Gerdan,
This is an internal address that should not be exposed:
postgresql@coelho.net
I'm unsure why it gets substituted by the "commitfest application"...
When i try apply this patch he failed with a following messenger:
It just worked for me on head with
git checkou
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, passed
When i try apply this patch he failed with a following messenger:
File t
Seeing it as is, it calls for having "SERVER_VERSION" as well, but I'm not
sure of the better way to get it. I tried with "SELECT VERSION() AS
SERVER_VERSION \gset" but varnames are lowerized.
The problem there is you can't get version() without an extra round trip
to the server --- and an ext
[ psql-version-num-8.patch ]
Pushed with some minor additional fiddling.
Ok, Thanks. I also noticed the reformating.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I wrote:
> "Daniel Verite" writes:
>> That would look like the following, for example, with a 3-space margin
>> for the description:
>> AUTOCOMMIT
>>If set, successful SQL commands are automatically committed
> But we could do something close to that, say two-space indent for the
> variable
Fabien COELHO writes:
> [ psql-version-num-8.patch ]
Pushed with some minor additional fiddling.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacke
I think we should go with Daniel's idea for all three parts.
I'm okay with that, although probably it should be an independent patch.
In the documentation, I do not think that both SERVER_VERSION_NAME and
_NUM (or whatever their chosen name) deserve two independent explanations
with heavy re
Fabien COELHO writes:
> I also like Daniel's idea to update formatting rules, eg following what is
> done for environment variables and accepting that it won't fit in one page
> anyway.
Yeah. When you look at all three portions of the helpVariables output,
it's clear that we have faced this is
Hello Tom,
So I thought we were done bikeshedding the variable names for this
feature, but as I was reviewing the patch with intent to commit,
I noticed you hadn't updated helpVariables() to mention them.
Indeed.
Possibly you missed this because it doesn't mention VERSION either,
but that d
2017-09-04 19:35 GMT+02:00 Tom Lane :
> "Daniel Verite" writes:
> > The two-space left margin on the entire block does not add that
> > much to readability, IMV, so maybe we could reclaim these
> > two characters.
>
> Well, it's a sub-list of the entire output of helpVariables(), so
> I think som
"Daniel Verite" writes:
> The two-space left margin on the entire block does not add that
> much to readability, IMV, so maybe we could reclaim these
> two characters.
Well, it's a sub-list of the entire output of helpVariables(), so
I think some indentation is a good idea.
> That would look lik
2017-09-04 19:08 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > 2017-09-04 18:56 GMT+02:00 Tom Lane :
> >> Just had another idea: maybe make the new variable names
> >> SERVER_VERSION_S
> >> SERVER_VERSION_N
> >> VERSION_S
> >> VERSION_N
>
> > SERVER_VERSION_STR looks better than this.
>
> I du
Tom Lane wrote:
> Since we've blown past 80 columns on some of the other
> output, maybe that doesn't matter. Or maybe we should shorten this
> variable name so it doesn't force reformatting of all this text.
The two-space left margin on the entire block does not add that
much to readabi
Pavel Stehule writes:
> 2017-09-04 18:56 GMT+02:00 Tom Lane :
>> Just had another idea: maybe make the new variable names
>> SERVER_VERSION_S
>> SERVER_VERSION_N
>> VERSION_S
>> VERSION_N
> SERVER_VERSION_STR looks better than this.
I dunno, I'm not very pleased with the "STR" idea because the v
2017-09-04 18:56 GMT+02:00 Tom Lane :
> I wrote:
> > ... Or maybe we should shorten this
> > variable name so it doesn't force reformatting of all this text.
> > Possible ideas include "DB_VERSION_NAME", "SERVER_VER_NAME", or
> > "SERVER_VERSION_STR". (The last saves only one character, whereas
>
Hi
2017-09-04 18:31 GMT+02:00 Tom Lane :
> So I thought we were done bikeshedding the variable names for this
> feature, but as I was reviewing the patch with intent to commit,
> I noticed you hadn't updated helpVariables() to mention them.
> Possibly you missed this because it doesn't mention VE
I wrote:
> ... Or maybe we should shorten this
> variable name so it doesn't force reformatting of all this text.
> Possible ideas include "DB_VERSION_NAME", "SERVER_VER_NAME", or
> "SERVER_VERSION_STR". (The last saves only one character, whereas
> we really need to save two if we're trying not t
So I thought we were done bikeshedding the variable names for this
feature, but as I was reviewing the patch with intent to commit,
I noticed you hadn't updated helpVariables() to mention them.
Possibly you missed this because it doesn't mention VERSION either,
but that doesn't seem very defensible
Spending developer time to write code for the hypothetical someone running
a psql version 11 linked to a libpq < 7.4, if it can even link, does not
look like a very good investment... Anyway, here is required the update.
The question is the server's version, not libpq.
Ok.
Modern psql does
Fabien COELHO writes:
> Spending developer time to write code for the hypothetical someone running
> a psql version 11 linked to a libpq < 7.4, if it can even link, does not
> look like a very good investment... Anyway, here is required the update.
The question is the server's version, not libp
Hello Tom,
I think you are taking unreasonable shortcuts here:
+ SetVariable(pset.vars, "SERVER_VERSION_NAME", PQparameterStatus(pset.db,
"server_version"));
The existing code in connection_warnings() does this:
const char *server_version;
/* Try to get full tex
Fabien COELHO writes:
> So basically the only thing needed from Robert & you seems to change
> "11.0" to "11devel", which is fine with me.
> The attached v5 does that.
I think you are taking unreasonable shortcuts here:
+ SetVariable(pset.vars, "SERVER_VERSION_NAME",
PQparameterStatus(ps
Hello Tom,
I understand that you would prefer VERSION_NAME to show something like
"11devel, server 9.6.4"
No, that's not what I said. I'm just complaining that as the patch stands
it will set SERVER_NAME to "11.0", where I think it should say "11devel"
(as of today).
Ok.
[...]
VE
Fabien COELHO writes:
>> OK, but if human-friendly display is the use-case then it ought to
>> duplicate what psql itself would print in, eg, the startup message about
>> server version mismatch. The v4 patch does not, in particular it neglects
>> PQparameterStatus(pset.db, "server_version"). Th
Hello Tom,
... 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 \echo this thing
doesn't work on :VER
On Fri, Aug 25, 2017 at 6:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Aug 25, 2017 at 6:09 PM, Tom Lane wrote:
>>> ... 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
>> vers
Robert Haas writes:
> On Fri, Aug 25, 2017 at 6:09 PM, Tom Lane wrote:
>> ... 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 i
On Fri, Aug 25, 2017 at 6:09 PM, Tom Lane 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 us
Robert Haas writes:
> I am attempting to understand the status of this patch. It looks like
> the patch that was the original subject of this thread was committed
> as f833c847b8fa4782efab45c8371d3cee64292d9b on April 1st by Tom, who
> was its author. Subsequently, a new patch not obviously relat
On Sun, May 21, 2017 at 11:37 AM, Fabien COELHO wrote:
>> This patch has trivial implementation - and there are not any objection to
>> used new variable names.
>>
>> 1. there was not any problem with patching, compiling
>> 2. all regress tests passed
>> 3. no problems with doc build
>>
>> I'll ma
Thanks for the pointer. I grepped for them without success. Here is a v4.
I am sending a review of this patch.
This patch has trivial implementation - and there are not any objection to
used new variable names.
1. there was not any problem with patching, compiling
2. all regress tests passed
Hi
2017-04-02 21:57 GMT+02:00 Fabien COELHO :
>
> More to the point, we already have that. See c.h:
>>
>> #define CppAsString(identifier) #identifier
>> #define CppAsString2(x) CppAsString(x)
>>
>
> Thanks for the pointer. I grepped for them without success. Here is a v4.
I am
2017-04-17 10:58 GMT+02:00 Fabien COELHO :
>
> I don't think so :?xxx is good idea, because for me :xxx is related to
>> content, not to metadata
>>
>
> Hmmm. Indeed it is not. I do not see it as an issue, but it is a good
> point.
>
> Consider perl "defined $x" or "exists $f{k}". $x/$f{k} should
I don't think so :?xxx is good idea, because for me :xxx is related to
content, not to metadata
Hmmm. Indeed it is not. I do not see it as an issue, but it is a good
point.
Consider perl "defined $x" or "exists $f{k}". $x/$f{k} should be contents,
but it is not, the dereferencing is suspen
>
>
> 4. because pgbench doesn't do early variable evaluation, implementation of
>> "defined" function is easy - we can introduce some new syntax for
>> implementation some bash patterns like "default value" or "own undefined
>> message"
>>
>
> Maybe. ISTM that a :* syntax should be thought for so
Hello Pavel,
A more detailed answer to your many points.
The pgbench expression language is perfect for us - there is not any new
dependency - it is working on all supported platforms.
Can be nice, if we can reuse pgbench expressions in psql - there are some
task that should be solved first (
2017-04-17 1:00 GMT+02:00 Fabien COELHO :
>
> I checked the pgbench expr related code.
>>
>
> 2. move pgbench expressions to separate module
>>
>
> Probably already existing "fe_utils".
>
> 3. teach pgbench expressions booleans
>>
>
> See https://commitfest.postgresql.org/14/985/
so some work is
I checked the pgbench expr related code.
2. move pgbench expressions to separate module
Probably already existing "fe_utils".
3. teach pgbench expressions booleans
See https://commitfest.postgresql.org/14/985/
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
2017-04-12 1:42 GMT+02:00 Fabien COELHO :
>
> Hmmm. Although I do not buy this, it could work as a replacement for \set
>>> which it seems cannot be upgraded because some people may rely on it to
>>> just store whatever comes after it in a variable.
>>>
>>
>> I have no strong opinion on how expres
Fabien COELHO wrote:
> Pavel also suggested some support for TEXT, although I would like to see a
> use case. That could be another extension to the engine.
SQLSTATE is text.
Also when issuing "psql -v someoption=value -f script", it's reasonable
to want to compare :someoptionvar to 'so
Hmmm. Although I do not buy this, it could work as a replacement for \set
which it seems cannot be upgraded because some people may rely on it to
just store whatever comes after it in a variable.
I have no strong opinion on how expressive expressions should be, but
having a separate \expr (or
On Tue, Apr 11, 2017 at 2:56 AM, Fabien COELHO wrote:
>
> Hello Pavel,
>
> I think so some local expression evaluation could be - but it should not be
>> placed in \if statement
>>
>
> Why?
>
> \expr issupported :VERSION_NUM >= 1
>>
>
> Hmmm. Although I do not buy this, it could work as a rep
2017-04-11 9:07 GMT+02:00 Fabien COELHO :
>
> I think so implementation of simple expression evaluation should not be
>> hard
>>
>
> Indeed it is not hard, it is rather a matter of deciding what it should
> do, and the syntax to do it.
>
> - really just - we can expect so any variable will be repl
I think so implementation of simple expression evaluation should not be
hard
Indeed it is not hard, it is rather a matter of deciding what it should
do, and the syntax to do it.
- really just - we can expect so any variable will be replaced by
const in expression
Num (<|>|=|<=|>=) Num
<
2017-04-11 8:56 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> I think so some local expression evaluation could be - but it should not be
>> placed in \if statement
>>
>
> Why?
>
> \expr issupported :VERSION_NUM >= 1
>>
>
> Hmmm. Although I do not buy this, it could work as a replacement for
>
> \else
> \if :somevar > 1 and SERVER_NUM >= 10
>
should be
\if :somevar > 1 and :SERVER_NUM >= 10
> ...
> \end
>
>
Hello Pavel,
I think so some local expression evaluation could be - but it should not be
placed in \if statement
Why?
\expr issupported :VERSION_NUM >= 1
Hmmm. Although I do not buy this, it could work as a replacement for \set
which it seems cannot be upgraded because some people ma
2017-04-11 8:17 GMT+02:00 Fabien COELHO :
>
> Hello Greg,
>
> SELECT some-boolean-expression AS okay \gset
>>> \if :okay
>>>
>>
>> Am I the only one who thinks that even if \if got the ability to
>> evaluate arbitrary SQL queries I would probably still always write
>> things as above?
>>
>
> I
Hello Greg,
SELECT some-boolean-expression AS okay \gset
\if :okay
Am I the only one who thinks that even if \if got the ability to
evaluate arbitrary SQL queries I would probably still always write
things as above?
I think putting arbitrary SQL expressions (let alone queries) would mak
2017-04-10 13:07 GMT+02:00 Greg Stark :
> On 2 April 2017 at 07:53, Fabien COELHO wrote:
> > Note that this is already available indirectly, as show in the
> > documentation.
> >
> > SELECT some-boolean-expression AS okay \gset
> > \if :okay
> > \echo boolean expression was true
> > \el
On 2 April 2017 at 07:53, Fabien COELHO wrote:
> Note that this is already available indirectly, as show in the
> documentation.
>
> SELECT some-boolean-expression AS okay \gset
> \if :okay
> \echo boolean expression was true
> \else
> \echo boolean expression was false
> \endif
2017-04-04 9:53 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> The expression evaluation is interesting question, but there is a
>> workaround - we can use \gset already.
>>
>
> Yes, that is a good point. It is a little bit inconvenient because it
> requires a dummy variable name each time for tes
Hello Pavel,
The expression evaluation is interesting question, but there is a
workaround - we can use \gset already.
Yes, that is a good point. It is a little bit inconvenient because it
requires a dummy variable name each time for testing.
SELECT whatever AS somename \gset
\if :somen
2017-04-03 21:24 GMT+02:00 Fabien COELHO :
>
> Hello Tom,
>
> \if [select current_setting('server_version_num')::int < 11]
>>>
>>
>> I really dislike this syntax proposal.
>>
>
> It would get us into having to count nested brackets, and distinguish
>> quoted from unquoted brackets, and so on
On Mon, Apr 3, 2017 at 5:12 AM, Daniel Verite
wrote:
> Queries can be as complex as necessary, they just have to fit in one line.
Line continuation in general is missed though I thought something already
when in for 10.0 that improves upon this...
> In no way at all,in the sense that, eithe
\set d sqrt(1 + random(1000) * 17)
\echo :d
sqrt(1+random(1000)*17)
I assume we want to keep that pre-existing behavior of \set in
psql,
Ok. So no interpreted expression ever in psql's \set for backward
compatibility.
that is, making a copy of that string and associating a name to it,
whe
>
> I assume we want to keep that pre-existing behavior of \set in
> psql, that is, making a copy of that string and associating a
> name to it, whereas I guess pgbench computes a value from it and
> stores that value.
>
Maybe a \set-variant called \expr?
Fabien COELHO wrote:
> Now it could be decided that \set in psql stays simplistic because it is
> not needed as much as it is with pgbench. Fine with me.
It's not just that. It's that currently, if we do in psql:
\set d sqrt(1 + random(1000) * 17)
then we get that:
\echo :d
sqrt(1+ran
[...] but OTOH "\if sql 1 from table where expr" looks awkward. Given an
implicit select, I would prefer "\if exists (select 1 from table where
expr)" but now it's not shorter.
Possibly, but it is just an SQL expression, which looks good in the middle
of an sql script.
An advantage of pr
Hello Tom,
\if [select current_setting('server_version_num')::int < 11]
I really dislike this syntax proposal.
It would get us into having to count nested brackets, and distinguish
quoted from unquoted brackets, and so on ... and for what? It's not
really better than
\if sql se
Hello Daniel,
- how would it work, both with \set ... and \if ...?
The idea is that the need to have two command (a SELECT .. \gset
followed by an \if) and a temporary variable in-between would be
lifted by implementing a close equivalent in one command.
It would behave essentially the same
Tom Lane wrote:
> I really dislike this syntax proposal. It would get us into having
> to count nested brackets, and distinguish quoted from unquoted brackets,
> and so on ... and for what? It's not really better than
>
> \if sql select 1 from pg_catalog.pg_extension where extname='pg
"Daniel Verite" writes:
> Let's imagine that psql would support a syntax like this:
> \if [select current_setting('server_version_num')::int < 11]
> or
> \if [select 1 from pg_catalog.pg_extension where extname='pgcrypto']
I really dislike this syntax proposal. It would get us into havin
Fabien COELHO wrote:
> My 0.02 € about server-side expressions: ISTM that there is nothing
> obvious/easy to do to include these:
>
> - how would it work, both with \set ... and \if ...?
The idea is that the need to have two command (a SELECT .. \gset
followed by an \if) and a tempora
Hello Tom,
about version numbers [...] Of course, there are probably other ways to
do that, but my point is that you haven't made a case why we need to put
this in now rather than later.
Indeed, I have not. What about having the ability to test for minor
versions?
\if false
-- pre 1
Fabien COELHO writes:
>>> - how desirable/useful is it to have this in 10?
>> Extensions and extension-ish packages will love the _NUM vars.
> H. I'm afraid pg extension scripts (for CREATE EXTENSION) are not
> executed through psql, but server side directly, so there is not much
> backsla
More to the point, we already have that. See c.h:
#define CppAsString(identifier) #identifier
#define CppAsString2(x) CppAsString(x)
Thanks for the pointer. I grepped for them without success. Here is a v4.
--
Fabiendiff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/
src/tools/msvc/Solution.pm:s{PG_VERSION_STR "[^"]+"}{__STRINGIFY(x)
#x\n#define __STRINGIFY2(z) __STRINGIFY(z)\n#define PG_VERSION_STR
"PostgreSQL $self->{strver}$extraver, compiled by Visual C++ build "
__STRINGIFY2(_MSC_VER) ", $bits-bit"};
Well, this is the same hack.
Without digging too
Corey Huinker writes:
> Looking at #define STRINGIFY(), I got curious where else STRINGIFY was used:
> Without digging too deep, it seems like the redefinition wouldn't be
> harmful, but it might make sense to not use the name STRINGIFY() if only to
> avoid confusion with Solution.pm.
More to the
On Sun, Apr 2, 2017 at 12:29 PM, Fabien COELHO wrote:
>
> Hello Corey,
>
> I'm anxious to help with these patches, but they seem a bit of a moving
>> target. Happy to jump in and review as soon as we've settled on what
>> should
>> be done.
>>
>
> The "v3" I sent basically adds both client & serv
Hello Corey,
I'm anxious to help with these patches, but they seem a bit of a moving
target. Happy to jump in and review as soon as we've settled on what should
be done.
The "v3" I sent basically adds both client & server version numbers in
client-side variables, basically same code as sugge
On Sun, Apr 2, 2017 at 11:16 AM, Pavel Stehule
wrote:
>
>
> 2017-04-02 13:13 GMT+02:00 Fabien COELHO :
>
>>
>> Hello Pavel,
>>
>> \echo :VERSION
PostgreSQL 10devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609, 64-bit
Probably some
2017-04-02 13:13 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> \echo :VERSION
>>> PostgreSQL 10devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
>>> 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609, 64-bit
>>>
>>> Probably some :VERSION_NUM would make some sense. See attached PoC patch.
>>> Would i
Hello Daniel,
SELECT some-boolean-expression AS okay \gset
\if :okay
Yes, the question was whether we leave it as that for v10,
or if it's worth a last-minute improvement for usability,
assuming it's doable, similarly to what $subject does to backtick
expansion for external evaluation.
Fabien COELHO wrote:
> Note that this is already available indirectly, as show in the
> documentation.
>
> SELECT some-boolean-expression AS okay \gset
> \if :okay
> \echo boolean expression was true
> \else
> \echo boolean expression was false
> \endif
Yes, the question
Can be SERVER_VERSION_NUM taken from connection info?
Here is a version with that, quite easy as well as the information was
already there for other checks.
I have not updated "help.c" because the initial VERSION was not presented
there in the first place.
Here is a v3 to fix the documen
Can be SERVER_VERSION_NUM taken from connection info?
Here is a version with that, quite easy as well as the information was
already there for other checks.
I have not updated "help.c" because the initial VERSION was not presented
there in the first place.
--
Fabien.diff --git a/doc/src/
Hello Pavel,
\echo :VERSION
PostgreSQL 10devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609, 64-bit
Probably some :VERSION_NUM would make some sense. See attached PoC patch.
Would it make sense?
Maybe better name for you CLIENT_VERSION_NUM
If i
2017-04-02 9:45 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> For this case can be nice to have function that returns server version as
>> number some like version_num() .. 1
>>
>
> The server side information can be queried:
>
> SELECT current_setting(‘server_version_num’)
> AS server_
2017-04-02 9:45 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> For this case can be nice to have function that returns server version as
>> number some like version_num() .. 1
>>
>
> The server side information can be queried:
>
> SELECT current_setting(‘server_version_num’)
> AS server_
For this case can be nice to have function that returns server version as
number
some like version_num() .. 1
Another possible trick to get out of a script which does not support \if,
relying on the fact that the unexpected command is simply ignored:
-- exit version below 10
\if fals
Hello Pavel,
For this case can be nice to have function that returns server version
as number some like version_num() .. 1
The server side information can be queried:
SELECT current_setting(‘server_version_num’)
AS server_version_num \gset
-- 90602
However client side is not so
2017-04-02 8:53 GMT+02:00 Fabien COELHO :
>
> Bonjour Daniel,
>
> I think that users would rather have the option to just put
>> an SQL expression behind \if.
>>
>
> Note that this is already available indirectly, as show in the
> documentation.
>
> SELECT some-boolean-expression AS okay \gset
>
Bonjour Daniel,
I think that users would rather have the option to just put
an SQL expression behind \if.
Note that this is already available indirectly, as show in the
documentation.
SELECT some-boolean-expression AS okay \gset
\if :okay
\echo boolean expression was true
\else
Corey Huinker writes:
> On Thu, Mar 30, 2017 at 1:33 PM, Tom Lane wrote:
>> single-quoted according to Unix shell conventions. (So the
>> processing would be a bit different from what it is for the
>> same notation in SQL contexts.)
> +1
Here's a proposed patch for this. I used the existing a
"Daniel Verite" writes:
> ISTM that expr is too painful to use to be seen as the
> idiomatic way of achieving comparison in psql.
I'm not proposing it as the best permanent solution, just saying
that having this in v10 is a lot better than having nothing in v10.
And we certainly aren't going to g
Corey Huinker writes:
> On Thu, Mar 30, 2017 at 1:33 PM, Tom Lane wrote:
>> single-quoted according to Unix shell conventions. (So the
>> processing would be a bit different from what it is for the
>> same notation in SQL contexts.)
> Any reason we wouldn't do :"VARIABLE" as well?
Well, what w
2017-03-31 15:00 GMT+02:00 Daniel Verite :
> Tom Lane wrote:
>
> > Thoughts?
>
> ISTM that expr is too painful to use to be seen as the
> idiomatic way of achieving comparison in psql.
>
> Among its disadvantages, it won't work on windows, and its
> interface is hard to work with due to th
Tom Lane wrote:
> Thoughts?
ISTM that expr is too painful to use to be seen as the
idiomatic way of achieving comparison in psql.
Among its disadvantages, it won't work on windows, and its
interface is hard to work with due to the necessary
quoting of half its operators, and the mandator
On Thu, Mar 30, 2017 at 1:33 PM, Tom Lane wrote:
> single-quoted according to Unix shell conventions. (So the
> processing would be a bit different from what it is for the
> same notation in SQL contexts.)
>
+1
Having been bit by format '%L' prepending an 'E' to any string that happens
to have
On Fri, Mar 31, 2017 at 2:33 AM, Tom Lane wrote:
> Awhile back in the discussion about the \if feature for psql,
> I'd pointed out that you shouldn't really need very much in
> the way of boolean-expression evaluation smarts, because you
> ought to be able to use a backtick shell escape:
>
>
95 matches
Mail list logo
