Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

> > I'm not sure whether there's a way to fix this that doesn't break other > cases. We could retrieve the pg_database.datcollate string from the > remote, but that doesn't necessarily match up with any collation name > we know about locally. One pretty common failure mode would be that > the

Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

> > > The collation column is empty here, which means that collation for > str* columns is default collation i.e. C. This isn't true, since the > default ncollation on the foreign server is different from the default > collation of local database. AFAIU, import foreign schema should have > set

[HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

We are having an issue with a query that will return no results when the query does a merge join with a foreign table, but (correctly) returns results when using a hash join. Here is the situation on the "remote" database (9.5): # \d+ table_with_en_us_utf8_encoding Table

Re: [HACKERS] psql - add ability to test whether a variable exists

On Sat, Aug 26, 2017 at 2:09 PM, Pavel Stehule wrote: > > > 2017-08-26 19:55 GMT+02:00 Fabien COELHO : > >> >> Any colon prefixed syntax can be made to work because it is enough for >>> the lexer to detect and handle... so >>> >>> :{defined varname}

Re: [HACKERS] CTE inlining

> > I get that people with gigantic PostgreSQL installations with > stringent performance requirements sometimes need to do odd things to > squeeze out the last few percentage points of performance. As the > people (well, at least the people close to the ground) at these > organizations are fully

Re: [HACKERS] CTE inlining

On Mon, May 1, 2017 at 10:26 AM, Andreas Karlsson wrote: > What about WITH MATERIALIZED, borrowing from the MySQL terminology > "materialized subquery"? +1, you beat me to it.

Re: [HACKERS] Undefined psql variables

> > > > I suggest to reuse pgbench expression engine, developed by Haas Robert:-) > > Not a bad idea (though I'm sure there are other reasonable options, too). > > I don't want to stand in the way of any progress in getting expressions into \if and some subspecies of \set. But, assuming we don't

Re: [HACKERS] delta relations in AFTER triggers

> > Great. Thanks. I wonder if there is some way we can automatically > include code fragments in the documentation without keeping them in > sync manually. > > In whatever extra docs you add, could you include an example of an INSERT ON CONFLICT, and potentially a CTE query that does two

Re: [HACKERS] Variable substitution in psql backtick expansion

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,

Re: [HACKERS] Undefined psql variables

On Sun, Apr 2, 2017 at 4:57 PM, Fabien COELHO wrote: > > I'm inclined to suggest that we should require all extensions beyond the >> boolean-literal case to be set up as a keyword followed by appropriate >> argument(s); that seems like it's enough to prevent syntax conflicts

Re: [HACKERS] Variable substitution in psql backtick expansion

> > 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?

Re: [HACKERS] delta relations in AFTER triggers

> > > That, and I suspect that people will start using this infrastructure > > for some very cool projects. > > Yeah, I was excited to see this committed. It practically begs to be > used for plpgsql TABLE valued variables backed by tuplestores. > (also very excited about this!)

Re: [HACKERS] Variable substitution in psql backtick expansion

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

Re: [HACKERS] asynchronous execution

> > > I'll continue working on this from this point aiming to the next > commit fest. > > This probably will not surprise you given the many commits in the past 2 weeks, but the patches no longer apply to master: $ git apply ~/async/0001-Allow-wait-event-set-to-be-registered-to-resource-ow.patch

Re: [HACKERS] Variable substitution in psql backtick expansion

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)

Re: [HACKERS] Undefined psql variables

On Mon, Jan 23, 2017 at 12:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Corey Huinker <corey.huin...@gmail.com> writes: > > I was giving some thought to how psql handles undefined variables. > > I would like an option where either psql can provide an alternate

Re: [HACKERS] Variable substitution in psql backtick expansion

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

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

Corey can submit another patch with the exit 3 test removed. > > -- > Fabien. > From 9caa338fa085bc1c0ee16f22c0c1c8d3c8fc1697 Mon Sep 17 00:00:00 2001 From: Corey Huinker <corey.huin...@moat.com> Date: Wed, 29 Mar 2017 15:30:22 -0400 Subject: [PATCH] psql if v29 --- doc/sr

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > > 0001+0002 patch primarily for ease of review. will be following with a > single v28 patch shortly. > 0001-psql-if-v28.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Mon, Mar 27, 2017 at 3:25 PM, Fabien COELHO wrote: > > And here you go >> > > Patch applies cleany, make check ok. Looks pretty good. > > A minor detail I have just noticed, sorry: now that options are discarded > by functions, some string variable declarations should be

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Mon, Mar 27, 2017 at 10:34 AM, Fabien COELHO wrote: > > Hello, > > I think that you could use another pattern where you init the >>> PQExpBufferData structure instead of create it, so that only the string >>> is >>> malloced. >>> >> >> In v26, I have the functions return

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

;, and do not seem to rely on a > format: > > Here's an addendum that does that. I can combine them in v27, but figured this was quicker. From 2fa083eb0115278f817a2d1d0439a47951a9c48b Mon Sep 17 00:00:00 2001 From: Corey Huinker <corey.huin...@moat.com> Date: Mon, 27 Mar 2017 10:07:3

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

c". It is pre-existing. Maybe this patch will inspire someone else to make the other more consistent. v26 attached From fc0c466b0331839efe722d089a8ead521e8a827e Mon Sep 17 00:00:00 2001 From: Corey Huinker <corey.huin...@moat.com> Date: Sun, 26 Mar 2017 17:30:5

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

in a later patch for clarity On Fri, Mar 24, 2017 at 4:33 PM, Corey Huinker <corey.huin...@gmail.com> wrote: > On Fri, Mar 24, 2017 at 4:10 PM, Fabien COELHO <coe...@cri.ensmp.fr> > wrote: > >> >> Hello Corey, >> >> I wished for the same thing, happy to us

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Fri, Mar 24, 2017 at 4:10 PM, Fabien COELHO wrote: > > Hello Corey, > > I wished for the same thing, happy to use one if it is made known to me. >> I pulled that pattern from somewhere else in the code, and given that the >> max number of args for a command is around 4,

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > > A few comments about the patch. > > Patch applies. "make check" ok. > > As already pointed out, there is one useless file in the patch. > > Although currently there is only one expected argument for boolean > expressions, the n² concatenation algorithm in gather_boolean_expression is > not

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Sun, Mar 19, 2017 at 1:18 PM, Fabien COELHO wrote: > > Hello Corey, > > v24 highlights: >> > > The v24 patch is twice larger that the previous submission. Sigh. > > If I'm reading headers correctly, it seems that it adds an > "expected/psql-on-error-stop.out" file without

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Sun, Mar 19, 2017 at 4:23 PM, Fabien COELHO wrote: > > Hello Tom, > > I'm not entirely convinced that function-per-command is an improvement >> though. [...] >> > > I don't have a definite opinion on that core question yet, since I've not >> read this version of the

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Fri, Mar 17, 2017 at 2:18 PM, Corey Huinker <corey.huin...@gmail.com> wrote: > >> > \set x 'arg1 arg2' >> >> > \if false >> > \cmd_that_takes_exactly_two_args :x >> > \endif >> >> Yeah, thr

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > > > \set x 'arg1 arg2' > > > \if false > > \cmd_that_takes_exactly_two_args :x > > \endif > > Yeah, throwing errors for bad arguments would also need to be suppressed. > > regards, tom lane > Ok, barring other feedback, I'm going to take my marching orders as "make

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > > In the end, I suspect that teaching all the backslash commands to do > nothing after absorbing their arguments is likely to be the least messy > way to tackle this, even if it makes for a rather bulky patch. > > Perhaps, but just glancing at \connect makes me think that for some commands

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Fri, Mar 17, 2017 at 11:42 AM, Tom Lane wrote: > Fabien COELHO writes: > >> I also fear that there are corner cases where the behavior would still > >> be inconsistent. Consider > >> > >> \if ... > >> \set foo `echo \endif should not appear here` > >

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > > command.c:38:25: fatal error: conditional.h: No such file or directory > #include "conditional.h" > Odd, it's listed as a new file in git status. Anyway, my point of posting the WIP patch was to give people a reference point and spark discussion about the next step, and it succeeded at

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

.pa.us> wrote: > Corey Huinker <corey.huin...@gmail.com> writes: > > Ok, I've got some time now and I'm starting to dig into this. I'd like to > > restate what I *think* my feedback is, in case I missed or misunderstood > > something. > > ... > > 3. Ch

Re: [HACKERS] asynchronous execution

On Thu, Mar 16, 2017 at 4:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Corey Huinker <corey.huin...@gmail.com> writes: > > I reworked the test such that all of the foreign tables inherit from the > > same parent table, and if you query that you do get async execution

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Mon, Mar 13, 2017 at 5:21 PM, Tom Lane wrote: > "Daniel Verite" writes: > > Tom Lane wrote: > >> when we see \if is that we do nothing but absorb text > >> until we see the matching \endif. At that point we could bitch and > throw > >> everything

Re: [HACKERS] asynchronous execution

On Mon, Mar 13, 2017 at 9:28 PM, Amit Langote <langote_amit...@lab.ntt.co.jp > wrote: > On 2017/03/14 10:08, Corey Huinker wrote: > >> I don't think the plan itself will change as a result of applying this > >> patch. You might however be able to observe some performan

Re: [HACKERS] asynchronous execution

> > I don't think the plan itself will change as a result of applying this > patch. You might however be able to observe some performance improvement. > > Thanks, > Amit > I could see no performance improvement, even with 16 separate queries combined with UNION ALL. Query performance was always

Re: [HACKERS] asynchronous execution

On Mon, Mar 13, 2017 at 1:06 AM, Corey Huinker <corey.huin...@gmail.com> wrote: > >> I think it will, because Append itself has been made async-capable by one >> of the patches and UNION ALL uses Append. But as mentioned above, only >> the postgres_fdw foreign tab

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > > Barring objection I'll push this so that Corey can rebase over it. > > regards, tom lane > Seems straightforward, and I appreciate you doing it for me!

Re: [HACKERS] asynchronous execution

> > > I think it will, because Append itself has been made async-capable by one > of the patches and UNION ALL uses Append. But as mentioned above, only > the postgres_fdw foreign tables will be able to utilize this for now. > > Ok, I'll re-run my test from a few weeks back and see if anything

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > > (1) document that \if-related commands MUST be on their own > line (i.e. like cpp #if directives?). > I have no opinion on whether \if-related comments must be on their own line, though I coded as if that were the case. I want to point out that the goal down the road is to allow

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Sun, Mar 12, 2017 at 1:52 AM, David G. Johnston < david.g.johns...@gmail.com> wrote: > > Oddly, Corey was using you as support for this position...though without an actual quote: > > """ Reading this, I started to wonder "so how did I get that impression?" and I found this from Feb 9: IMO, an

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Sat, Mar 11, 2017 at 4:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Corey Huinker <corey.huin...@gmail.com> writes: > > [ 0001.if_endif.v21.diff ] > > Starting to poke at this... the proposal to add prove checks for psql > just to see whether \if res

Re: [HACKERS] asynchronous execution

On Thu, Feb 23, 2017 at 6:59 AM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > 9e43e87 Patch fails on current master, but correctly applies to 9e43e87. Thanks for including the commit id. Regression tests pass. As with my last attempt at reviewing this patch, I'm confused

Re: [HACKERS] contrib modules and relkind check

On Tue, Feb 14, 2017 at 1:30 AM, Michael Paquier wrote: > Hm... It may be a good idea to be consistent on the whole system and > refer to "partitioned table" as a table without storage and used as an > entry point for partitions. The docs use this term in CREATE TABLE,

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Fri, Mar 3, 2017 at 1:25 AM, Fabien COELHO wrote: > > > For endif, I really exagerated, "switch { defaut: " is too much, please >> accept my apology. Maybe just do the pop & error reporting? >> > It seemed like overkill, but I decided to roll with it. > > Or maybe be

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > > For me, it is only slightly better: I think that for helping understanding > and maintenance, the automaton state transitions should be all clear and > loud in just one place, so I would really like to see a single common > structure: > > if (is "if") switch on all states; > else if (is

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Thu, Mar 2, 2017 at 1:23 AM, Fabien COELHO wrote: > > Hello Corey, > > That is accurate. The only positive it has is that the user only >> experiences one error, and it's the first error that was encountered if >> reading top-to-bottom, left to right. It is an issue of

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Wed, Mar 1, 2017 at 12:23 PM, Fabien COELHO wrote: > > Hello Corey, > > on elif >> if misplaced elif >> misplaced elif error >> else >> eval expression >> => possible eval error >> set new status if eval fine >> > > Currently it is really: > > switch

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Wed, Mar 1, 2017 at 3:07 AM, Fabien COELHO wrote: > > Hello Corey, > > It doesn't strike me as much cleaner, but it's no worse, either. >> > > Hmmm. > > The "if (x) { x = ... ; if (x) {" does not help much to improve > readability and understandability... > > My 0.02€

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > >> >> Alternatively if the structure must really be kept, then deal with errors >> in a first switch, read value *after* switch and deal with other errors >> there, then start a second switch, and adjust the documentation accordingly? >> >> switch >> errors >> read >> if >>

Re: [HACKERS] some dblink refactoring

On Tue, Feb 28, 2017 at 10:09 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > Here is a patch to refactor some macro hell in dblink. > > This patch was discussed in the background sessions thread as a > prerequisite for some work there, but I figure I'll make a separate > thread

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Sun, Feb 26, 2017 at 2:47 AM, Fabien COELHO wrote: > > Hello Corey, > > About v18: Patch applies, make check ok, psql tap tests ok. > > > ISTM that contrary to the documentation "\elif something" is not evaluated > in all cases, and the resulting code is harder to

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > Typo "unterminted". > Fixed. > The \if within the \if false branch is not tallied properly? Am I missing > something? > Nope, you found a bug. FIxed. Test-case added. > I changed the paragraph to >> > >Lines within false branches are parsed normally, however, any >> completed >>

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > I'm not sure that '@' is the best choice, but this is just one char. > I noticed that it takes precedence over '!'. Why not. ISTM that orthogonal > features are not shown independently, but this is a preexisting state, and > it allows to have a shorter prompt, so why not. > My reasoning was

Re: [HACKERS] Idea on how to simplify comparing two sets

> > FWIW I've found myself needing the precursor to this this (give me the > full diff) at least a couple times, and it's quite a PITA on anything but a > trivial relation. > > It's also not possible to make this easier via an SRF because you don't > know in advance what the result set looks like.

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > > Files "conditional.h" and "conditional.c" are missing from the patch. > > Also, is there a particular reason why tap test have been removed? That would be because I diffed against my last commit, not the master branch, sigh. v16 is everything v15 promised to be. diff --git

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Wed, Feb 22, 2017 at 6:15 PM, Corey Huinker <corey.huin...@gmail.com> wrote: > On Wed, Feb 22, 2017 at 5:59 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Ah, I see why *that* wants to know about it ... I think. I suppose you're >> arguing that variable expansi

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Wed, Feb 22, 2017 at 5:59 PM, Tom Lane wrote: > Ah, I see why *that* wants to know about it ... I think. I suppose you're > arguing that variable expansion shouldn't be able to insert, say, an \else > in a non-active branch? Maybe, but if it can insert an \else in an

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Wed, Feb 22, 2017 at 5:11 PM, Corey Huinker <corey.huin...@gmail.com> wrote: > Dunno, that sounds a lot like an "if the only tool I have is a hammer, >> then this must be a nail" argument. > > > More of a "don't rock the boat more than absolutely necess

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > > Dunno, that sounds a lot like an "if the only tool I have is a hammer, > then this must be a nail" argument. More of a "don't rock the boat more than absolutely necessary", but knowing that adding another global struct might be welcomed is good to know. > reasonable interpretation of

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Wed, Feb 22, 2017 at 4:00 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Corey Huinker <corey.huin...@gmail.com> writes: > >> but if you think that it should be somewhere else, please advise Corey > >> about where to put it. > > > Just a reminder that

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > but if you think that it should be somewhere else, please advise Corey > about where to put it. Just a reminder that I'm standing by for advice. The issue at hand is whether the if-state should be a part of the PsqlScanState, or if it should be a separate state variable owned by MainLoop()

Re: [HACKERS] COPY IN/BOTH vs. extended query mode

On Sun, Feb 19, 2017 at 9:04 AM, Robert Haas wrote: If you tried to write an SQL-callable function that internally started > and ended a copy from the client, then I think you would run into this > problem, and probably some others. > > That's it. I had a PoC patch

Re: [HACKERS] COPY IN/BOTH vs. extended query mode

On Mon, Feb 13, 2017 at 4:29 PM, Craig Ringer wrote: > > > On 14 Feb. 2017 06:15, "Robert Haas" wrote: > > On Mon, Jan 23, 2017 at 9:12 PM, Robert Haas > wrote: > > According to the documentation for COPY IN mode, "If

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Tue, Feb 14, 2017 at 4:44 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Corey Huinker <corey.huin...@gmail.com> writes: > > So moving the conditional stack back into PsqlScanState has some side > > effects: conditional.[ch] have to move to the fe_utils/ dirs, and

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > @in't gonna execute it? >> > > Hmmm... This is too much of an Americanism, IMHO. The @ looks like a handwritten 'a'. @in't gonna => ain't gonna => will not. It's a bad joke, made as a way of saying that I also could not think of a good mnemonic for '@' or ','. > I'm here all week, try the

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Mon, Feb 13, 2017 at 3:40 PM, Fabien COELHO wrote: > > Hello Robert, > > [...] I think we should try to make this REALLY simple. We don't really >> want to have everybody have to change their PROMPT1 and PROMPT2 strings for >> this one feature. >> > > Ok. I think that we

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Mon, Feb 13, 2017 at 11:29 AM, Robert Haas wrote: > possible states here. Just when you've figured out what tfzffft I agree with what you've said, but wanted to point out that any condition that follows a 'z' would itself be 'z'. Not that tfz is much better.

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Mon, Feb 13, 2017 at 3:04 PM, Fabien COELHO wrote: > > Hello Corey, > > That effort was creating as many headaches as it solved. Rolled back v12 >> except for doc paragraph, added more descriptive tap test names. Enjoy. >> > > The TAP tests are missing from the patch, not

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > I wasn't too happy with the extra param, either. Having moved the guts to >> conditional.c, I'm happy with that change and can move the stack head back >> to scan_state with a clear conscience. >> > > That effort was creating as many headaches as it solved. Rolled back v12 except for doc

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Mon, Feb 13, 2017 at 11:26 AM, Corey Huinker <corey.huin...@gmail.com> wrote: > ISTM that it is kind of a regression, because logically this is about the >> scan state so it should be in the corresponding structure, and having two >> structures to pass the scan state

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > ISTM that it is kind of a regression, because logically this is about the > scan state so it should be in the corresponding structure, and having two > structures to pass the scan state is not an improvement... I wasn't too happy with the extra param, either. Having moved the guts to

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > Maybe this can be a discussed in a follow-up patch and Corey should > proceed to finalize the if patch? In the event that we can leave prompting to a later patch, here are the v12 highlights: - created conditional.h and conditional.c which contain the functions with stack-ish

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Sat, Feb 11, 2017 at 5:57 PM, Greg Stark wrote: > On 10 February 2017 at 21:36, Fabien COELHO wrote: > >> command prompt is now > >> --- --- > >> \echo bob '' = initial state, no branch going on at

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Sat, Feb 11, 2017 at 3:48 PM, Fabien COELHO wrote: > > Just realized that '?' means "unknown transactional status" in %x. That >> might cause confusion if a person had a prompt of %x%R. Is that enough >> reason to pick a different cue? >> > > Argh. > > "\?\.?[tfz]" seems

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Sat, Feb 11, 2017 at 2:43 AM, Fabien COELHO wrote: > > Ok, so that's not just PROMPT_READY, that's every prompt...which might be >> ok. ? is a great optional cue, and you're thinking on 2 levels deep, 2nd >> level always being '.'? >> > > Yep. The idea is to keep it

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > calvin=> \if true > calvin?t=> SELECT 1 + > calvin?t-> 2; > 3 > calvin?t=> \if true > calvin?t=> \echo hello > hello > calvin?t=> \endif > calvin?t=> \else > calvin?z=> \echo ignored > calvin?t=> \endif > calvin=> > Ok, so that's not just PROMPT_READY, that's

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > Shouldn't there be some documentation changes to reflect the behavior on > errors? A precise paragraph about that would be welcome, IMHO. > Oddly enough, the documentation I wrote hadn't addressed invalid booleans, only the error messages did that. The new behavior certainly warrants a

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Thu, Feb 9, 2017 at 4:43 PM, Erik Rijkers <e...@xs4all.nl> wrote: > On 2017-02-09 22:15, Tom Lane wrote: > >> Corey Huinker <corey.huin...@gmail.com> writes: >> > > The feature now ( at patch v10) lets you break off with Ctrl-C anywhere. > I like it no

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Thu, Feb 9, 2017 at 3:13 PM, Tom Lane wrote: > Robert Haas writes: > > I (still) think this is a bad design. Even if you've got all the > > messages just right as things stand today, some new feature that comes > > along in the future can change

Re: [HACKERS] contrib modules and relkind check

On Mon, Feb 6, 2017 at 4:01 AM, Amit Langote wrote: > On 2017/01/24 15:35, Amit Langote wrote: > > On 2017/01/24 15:11, Michael Paquier wrote: > >> On Tue, Jan 24, 2017 at 2:14 PM, Amit Langote > >> wrote: > >>> Some contrib

Re: [HACKERS] Documentation improvements for partitioning

On Fri, Feb 3, 2017 at 4:15 AM, Amit Langote wrote: > Here are some patches to improve the documentation about partitioned > tables: > > 0001: Adds some details about partition_bound_spec to the CREATE TABLE > page, especially: > > - a note about inclusivity of

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > > It seems that ON_ERROR_STOP is mostly ignored by design when in > interactive mode, probably because it is nicer not to disconnect the user > who is actually typing things on a terminal. > > """ > ON_ERROR_STOP > > By default, command processing continues after an error. When this >

Re: [HACKERS] asynchronous execution

On Fri, Feb 3, 2017 at 5:04 AM, Antonin Houska wrote: > Kyotaro HORIGUCHI wrote: > > > I noticed that this patch is conflicting with 665d1fa (Logical > > replication) so I rebased this. Only executor/Makefile > > conflicted. > > I was lucky

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Mon, Feb 6, 2017 at 3:43 PM, Corey Huinker <corey.huin...@gmail.com> wrote: > I did some more tests. I found a subtlety that I missed before: when >> running under ON_ERROR_STOP, messages are not fully consistent: >> >> sh> cat test.sql >> \set ON_ERR

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > I did some more tests. I found a subtlety that I missed before: when > running under ON_ERROR_STOP, messages are not fully consistent: > > sh> cat test.sql > \set ON_ERROR_STOP on > \if error >\echo NO > \endif > \echo NO > > sh> ./psql < test.sql > SET > # ok > unrecognized value

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Mon, Feb 6, 2017 at 2:32 PM, Fabien COELHO wrote: > > Do you think the TAP tests would benefit from having the input described >> in a q(...) block rather than a string? >> > > My 0.02€: Not really, so I would not bother. It breaks perl indentation > and logic for a

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Mon, Feb 6, 2017 at 11:21 AM, Corey Huinker <corey.huin...@gmail.com> wrote: > >> Find attached a small patch to improve tap tests, which also checks that >>> psql really exited by checking that nothing is printed afterwards. >>> >> >> > Do y

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > > Find attached a small patch to improve tap tests, which also checks that >> psql really exited by checking that nothing is printed afterwards. >> > > Do you think the TAP tests would benefit from having the input described in a q(...) block rather than a string? q(\if false \echo a \elif

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > Hmmm. ISTM that control-c must at least reset the stack, otherwise their > is not easy way to get out. What can be left to another patch is doing a > control-C for contents and then another one for the stack when there is no > content. > And so it shall be. > - put Fabien's tap test in

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Sat, Feb 4, 2017 at 11:53 AM, Corey Huinker <corey.huin...@gmail.com> wrote: > The check I was suggesting on whether Ctrl+C has been pressed >> on an empty line seems harder to implement, because get_interactive() >> just calls readline() or fgets(), which block to return

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > The check I was suggesting on whether Ctrl+C has been pressed > on an empty line seems harder to implement, because get_interactive() > just calls readline() or fgets(), which block to return when a whole > line is ready. AFAICS psql can't know what was the edit-in-progress > when these

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > I noticed that the "barking" is conditional to "success". ISTM that it > should always "bark" in interactive mode, whether success or not. > "success" in those cases means "the expression was a valid boolean", and non-success cases (should) result in an error being printed regardless of

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Fri, Feb 3, 2017 at 7:42 PM, Jim Nasby wrote: > Since the current consensus is to be very verbose about \if, this is > obviously a non-issue. Maybe worth adding a 'I' case to %R, but no big deal > if that doesn't happen. I think we left the door open to a separate

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Fri, Feb 3, 2017 at 3:49 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Feb 3, 2017 at 11:08 AM, Corey Huinker <corey.huin...@gmail.com> > wrote: > > I could bulk up the error message on if/elif like such: > > > > if: true, executing commands. &g

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Fri, Feb 3, 2017 at 12:20 PM, Daniel Verite wrote: > If we add the functionality that Ctrl+C also exits from branches, > we could do it like the shell does Ctrl+D for logout, that is it > logs out only if the input buffer is empty, otherwise it does > the other

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > Can anyone think of a reason why Ctrl-C would be a bad idea? If not I'll >> start looking into it, as I'm not presently aware of what it is used for. >> > > Not me. > > Wikipedia, which holds all the knowledge in the universe, says: "In many > command-line interface environments, control-C is

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Fri, Feb 3, 2017 at 7:24 AM, Fabien COELHO wrote: > > Hello Erik, > > Still, it would be an improvement to be able to break out of an inactive >> \if-branch with Ctrl-C. >> > > Yes. > > '\endif' is too long to type, /and/ you have to know it. >> > > Yep. \if is shorter

  1   2   3   4   >