Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Wed, Jan 18, 2017 at 12:08 AM, Michael Paquier wrote: > On Wed, Jan 18, 2017 at 3:24 AM, Robert Haas > wrote: > > On Sat, Jan 14, 2017 at 12:22 AM, Tom Lane wrote: > >> > >> $ cat loop.sql > >> \if :x < 1000 > >> \echo

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Wed, Jan 18, 2017 at 3:24 AM, Robert Haas wrote: > On Sat, Jan 14, 2017 at 12:22 AM, Tom Lane wrote: >> >> $ cat loop.sql >> \if :x < 1000 >> \echo :x >> \set x :x + 1 >> \include loop.sql >> \fi >> $ psql --set x=0 -f loop.sql >> >> Somebody

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Sat, Jan 14, 2017 at 12:22 AM, Tom Lane wrote: > > $ cat loop.sql > \if :x < 1000 > \echo :x > \set x :x + 1 > \include loop.sql > \fi > $ psql --set x=0 -f loop.sql > > Somebody is going to think of that workaround for not having loops, and > then whine about how

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On 1/13/17 11:22 PM, Tom Lane wrote: I wonder what depth of include-file nesting psql can support, or whether we'll be able to fix it to optimize tail recursion of an include file. Because somebody will be asking for that if this is the toolset you give them. I think the solution to that is

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

$ cat loop.sql \if :x < 1000 \echo :x \set x :x + 1 \include loop.sql \fi $ psql --set x=0 -f loop.sql Nice one! CPP does not have arithmetic, so it is harder to do that because one must reimplement arithmetic with #if... Somebody is going to think of that workaround for not having

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Pavel Stehule writes: > 2017-01-14 0:20 GMT+01:00 Corey Huinker : >> - leaving loops out for now? > +1 I'm just going to say one thing about that: some people will remember that you can build a Turing machine with either conditionals+iteration

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hi 2017-01-14 0:20 GMT+01:00 Corey Huinker : > Ok, so activity on this thread has died down. I'm not sure if that's > consensus or exhaustion. > the original idea \quit_if is leaved? It is pity - it is common use case - and because we cannot to implement macros in psql,

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Ok, so activity on this thread has died down. I'm not sure if that's consensus or exhaustion. Are we good with: - implementing basic \if EXPR \elseif EXPR \else \endif, where the EXPR is an expression but is currently limited to a simple string that will be evaluated for truth via

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Mon, Dec 19, 2016 at 11:23 AM, Alvaro Herrera wrote: > David G. Johnston wrote: > > > Being able to do more conditional work in psql would make setting up more > > robust scripts easier and without either losing transaction capabilities > or > > session pooling for

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

David G. Johnston wrote: > Being able to do more conditional work in psql would make setting up more > robust scripts easier and without either losing transaction capabilities or > session pooling for improved performance when large numbers of small > commands are run in between flow control in

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

> > > > > -- this is how I fake an 'exit 0' now: > > \set work_needs_to_be_done t > > select > > case > > when :'work_needs_to_be_done'::boolean then '' > > else '\q' > > end as cmd > > \gset > > :cmd > > > > -- ridiculous example to illustrate complications in

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Mon, Dec 19, 2016 at 10:30 AM, Robert Haas wrote: > > I see your point. Just out of curiosity, why in the world don't you > use something other than psql for scripting? I mean, if you accessed > the data from Perl or Python or >

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-12-19 18:30 GMT+01:00 Robert Haas : > On Sat, Dec 17, 2016 at 3:39 PM, Corey Huinker > wrote: > >> To implement \while, we'd also need to remember previous commands so > >> that when we reach the end of the loop, we can rewind and put all of >

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Sat, Dec 17, 2016 at 3:39 PM, Corey Huinker wrote: >> To implement \while, we'd also need to remember previous commands so >> that when we reach the end of the loop, we can rewind and put all of >> those commands back on the stack to be executed again, or perhaps to >>

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

> > > (Or in other words, let's see \while ... \endloop in the minimal proposal > > as well, or at least a sketch of how to get there.) > > It seems to me that we could implement \if ... \else ...\endif by > having some kind of stack that indicates which constructs we're inside > of and whether

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Fri, Dec 16, 2016 at 12:40 PM, Tom Lane wrote: > Robert Haas writes: >> So I think it would be reasonable for somebody to implement \if, >> \elseif, \endif first, with the argument having to be, precisely, a >> single variable and nothing else (not

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-12-17 16:26 GMT+01:00 Fabien COELHO : > > Hello Tom, > > So I think it would be reasonable for somebody to implement \if, >>> \elseif, \endif first, with the argument having to be, precisely, a >>> single variable and nothing else (not even a negator). [...] >>> >> >

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello Tom, So I think it would be reasonable for somebody to implement \if, \elseif, \endif first, with the argument having to be, precisely, a single variable and nothing else (not even a negator). [...] This seems like a reasonable implementation plan to me, not least because it tackles

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-12-16 21:18 GMT+01:00 Robert Haas : > On Fri, Dec 16, 2016 at 12:28 PM, Pavel Stehule > wrote: > > why do you need special operator for negation? there is only one use > case. > > It can be solved by \if_not > > That's exactly the kind of

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Fri, Dec 16, 2016 at 12:28 PM, Pavel Stehule wrote: > why do you need special operator for negation? there is only one use case. > It can be solved by \if_not That's exactly the kind of thing I *don't* want to do. If you absolutely must have that and you can't wait

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-12-16 18:33 GMT+01:00 David G. Johnston : > On Fri, Dec 16, 2016 at 10:28 AM, Pavel Stehule > wrote: > >> 2016-12-16 18:21 GMT+01:00 David G. Johnston >> : >> >>> On Fri, Dec 16, 2016 at 9:55 AM, Robert Haas

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Robert Haas writes: > So I think it would be reasonable for somebody to implement \if, > \elseif, \endif first, with the argument having to be, precisely, a > single variable and nothing else (not even a negator). Then a future > patch could allow an expression there

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Fri, Dec 16, 2016 at 10:28 AM, Pavel Stehule wrote: > 2016-12-16 18:21 GMT+01:00 David G. Johnston : > >> On Fri, Dec 16, 2016 at 9:55 AM, Robert Haas >> wrote: >> >>> >>> If the expected committed patch set includes

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-12-16 18:21 GMT+01:00 David G. Johnston : > On Fri, Dec 16, 2016 at 9:55 AM, Robert Haas > wrote: > >> On Mon, Dec 5, 2016 at 12:32 PM, Robert Haas >> wrote: >> >> - possible incremental implemention steps on this

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Fri, Dec 16, 2016 at 9:55 AM, Robert Haas wrote: > On Mon, Dec 5, 2016 at 12:32 PM, Robert Haas > wrote: > >> - possible incremental implemention steps on this path: > >> > >> (1) minimal condition and expression, compatible with > >> a

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Mon, Dec 5, 2016 at 12:32 PM, Robert Haas wrote: >> - possible incremental implemention steps on this path: >> >> (1) minimal condition and expression, compatible with >> a possible future full-blown expression syntax >> >> \if :variable >> \if not

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

But if it does make sense to share, then that's another reason for not designing something ad-hoc for psql: integrating it later will be more work in total. Yes, but not much: evaluating "[!] :var" special syntax would be dropped, but I do not think that it is the main issue with these

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Tue, Dec 6, 2016 at 8:45 AM, Fabien COELHO wrote: > There are some differences: pgbench already had one operator at a time > expressions, while psql has survived till today with none, which suggest a > less pressing need. I don't really think so. People have been wanting

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello Robert, Your experience as an seasoned core developer and a committer is probably different:-) Well, everybody can have their own opinion on what is reasonable. Sure. There are times I argue for making a patch smaller (frequent) and times when I argue for making it bigger (rare).

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Tue, Dec 6, 2016 at 1:28 AM, Fabien COELHO wrote: > First, my experience as a basic patch submitter is that any patch which does > more than one thing at a time, even somehow closely related changes, is > asked to be split into distinct sub-patches, and is harder to get

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello Robert, Given the experience with pgbench and the psql context, I do not think that it would really need to go beyond step 2 above, but I agree that I may be wrong and it is best to be prepared for that from the start. Given the complexity and effort involved with (5), it seems wise to

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Sat, Dec 3, 2016 at 2:16 AM, Fabien COELHO wrote: >> My guess is that something comparable to where pgbench is would be a >> reasonable target --- not least because I think we should strive to >> reduce unnecessary differences between psql and pgbench metalanguages. >> >>

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-12-04 20:55 GMT+01:00 Fabien COELHO : > > Yes, that is a possibility, but this can already be queried into a >>> :-variable, so it is less indispensable. >>> >> >> can you show some examples, please? >> > > SELECT COUNT(*) AS has_unit_extension >FROM pg_extension

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Yes, that is a possibility, but this can already be queried into a :-variable, so it is less indispensable. can you show some examples, please? SELECT COUNT(*) AS has_unit_extension FROM pg_extension WHERE extname='unit' \gset \echo :has_unit_extension 1 So that \if !

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-12-04 17:35 GMT+01:00 Fabien COELHO : > > Hello Pavel, > > Some possibilities from pgbench can have sense in psql too - generating >> some random numbers from a range. >> > > Could you expand on the use case where this would be useful? > writing test cases > > In the

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello Pavel, Some possibilities from pgbench can have sense in psql too - generating some random numbers from a range. Could you expand on the use case where this would be useful? In the end we use one parser for psql and for pgbench. Note that "master" lexer is already shared, thanks to

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-12-03 8:16 GMT+01:00 Fabien COELHO : > > Hello, > > My guess is that something comparable to where pgbench is would be a >> reasonable target --- not least because I think we should strive to >> reduce unnecessary differences between psql and pgbench metalanguages. >> >>

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello, My guess is that something comparable to where pgbench is would be a reasonable target --- not least because I think we should strive to reduce unnecessary differences between psql and pgbench metalanguages. I'm not sure that I'm ready to propose that they should share the same

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On 12/2/16 9:24 AM, Robert Haas wrote: On Fri, Dec 2, 2016 at 11:12 AM, Corey Huinker wrote: 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"?

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Fri, Dec 2, 2016 at 11:12 AM, Corey Huinker wrote: > 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,

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Corey Huinker writes: > 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? My guess is that something

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

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

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Robert Haas 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 >

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Tue, Nov 29, 2016 at 4:43 AM, Pavel Stehule wrote: > I prefer the commands instead symbols - the parsing and processing symbols > should be more complex than it is now. A psql parser is very simple - and > any complex syntax enforces lot of code. > > \if_not Given the

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On 11/30/2016 03:47 AM, Fabien COELHO wrote: Hello Andrew, I cannot remember a language with elseif* variants, and I find them quite ugly, so from an aethetical point of view I would prefer to avoid that... On the other hand having an "else if" capability makes sense (eg do something

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello Andrew, I cannot remember a language with elseif* variants, and I find them quite ugly, so from an aethetical point of view I would prefer to avoid that... On the other hand having an "else if" capability makes sense (eg do something slightly different for various versions of pg), so

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello Tom, But really, \fi is something that could only be loved by a certain academic breed of hackers. Ah ah:-) I'll take that as a compliment:-) I'd go for \endif, probably. That still doesn't relate well with \unless, so +1 for \if, \ifnot, \else, and \endif. Ok, that is a clear

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

David Fetter writes: > On Tue, Nov 29, 2016 at 01:10:06PM +0100, Fabien COELHO wrote: >> If there is a negative condition syntax, I would slightly prefer \ifnot to >> \if_not or worse \unless. I would disaprove strongly of \unless because it >> looses the clear symmetry with a

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Tue, Nov 29, 2016 at 01:10:06PM +0100, Fabien COELHO wrote: > If there is a negative condition syntax, I would slightly prefer \ifnot to > \if_not or worse \unless. I would disaprove strongly of \unless because it > looses the clear symmetry with a closing \fi. I take it \sselnu is right out.

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On 11/29/2016 05:25 PM, David Steele wrote: On 11/29/16 5:08 PM, Andrew Dunstan wrote: On 11/29/2016 03:07 PM, Fabien COELHO wrote: I cannot remember a language with elseif* variants, and I find them quite ugly, so from an aethetical point of view I would prefer to avoid that... On the

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On 11/29/16 5:08 PM, Andrew Dunstan wrote: > > On 11/29/2016 03:07 PM, Fabien COELHO wrote: >> >> >> I cannot remember a language with elseif* variants, and I find them >> quite ugly, so from an aethetical point of view I would prefer to >> avoid that... On the other hand having an "else if"

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On 11/29/2016 03:07 PM, Fabien COELHO wrote: I cannot remember a language with elseif* variants, and I find them quite ugly, so from an aethetical point of view I would prefer to avoid that... On the other hand having an "else if" capability makes sense (eg do something slightly different

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

> > > Hmmm. Would you have an example use case that could not be done simply > with the previous ifs? cpp did that end ended up with a single if in the > end. I think this is what you're asking for... $ cat not_defined.sql select :'foo'; $ psql postgres --no-psqlrc -f not_defined.sql --set

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello Corey, I agree that the boolean tests available should be *very* simple, and all of the weight of complex calculation should be put in SQL, like we do with \gset Yes. I propose those be: \if STRING : true if STRING evaluates to true via ParseVariableBool, empty means false Yep.

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

> > My 0,02 €, which is just a personal opinion: > > I think that handling manually "!/not" would be worth the effort rather > than having two commands, especially if the boolean expression syntax may > be extended some day and the negative if would become obsolete. > > If there is a negative

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello Pavel, Now, the psql statements are designed do nothing in syntax error. I am not sure about be more strict in this case. I see strong advantages - but it can be little bit different than current behave. Indeed, an error on a conditional construct should stop the script, which is

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-11-29 8:44 GMT+01:00 Fabien COELHO : > > Hello, > > I think it's really time we seriously considered adding some flow >>> control logic, though. >>> >> >> Yeah, maybe. I'd be interested to see a fully worked out proposal >> for that. >> > > I agree that designing a

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello, I think it's really time we seriously considered adding some flow control logic, though. Yeah, maybe. I'd be interested to see a fully worked out proposal for that. I agree that designing a fuller proposal before including individual parts would be great and result in a more

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Andrew Dunstan writes: > On 11/28/2016 04:07 PM, Tom Lane wrote: >> ... We've generally refrained from inventing any control flow >> metacommands for psql > I think it's really time we seriously considered adding some flow > control logic, though. Yeah, maybe. I'd be

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On 11/28/2016 04:07 PM, Tom Lane wrote: ... We've generally refrained from inventing any control flow metacommands for psql I think it's really time we seriously considered adding some flow control logic, though. I'm mildly tired of either jumping through hoops to get around the lack or

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

> > > As far as the original problem goes, I wonder whether what you really >> want isn't a \quit command that lets you specify psql's exit code. >> > > The ability to specify an exit code was part of the brainstorming, yes. But with it was the ability to conditionally quit. > Actually, I'm

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Mon, Nov 28, 2016 at 2:07 PM, Tom Lane wrote: > Corey Huinker writes: > > On Mon, Nov 28, 2016 at 2:03 PM, Fabien COELHO > wrote: > There's no reason to assume a-priori that this patch creates either naming > conventions or

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Corey Huinker writes: > On Mon, Nov 28, 2016 at 2:03 PM, Fabien COELHO wrote: >> I'm wondering if an simplistic interpreted \if \elsif/\else \fi would make >> more sense: > The problem is that \if \elsif \else \fi is anything but simplistic, and >

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Mon, Nov 28, 2016 at 2:03 PM, Fabien COELHO wrote: > > Hello Corey, > > This patch adds two very simple psql commands: \quit_if and \quit_unless. >> > > A few comments about the feature design: > > I'm unsure about the name, esp with '_'. There are some \lo_* commands, >

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-11-28 20:03 GMT+01:00 Fabien COELHO : > > Hello Corey, > > This patch adds two very simple psql commands: \quit_if and \quit_unless. >> > > A few comments about the feature design: > > I'm unsure about the name, esp with '_'. There are some \lo_* commands, > but others

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello Corey, This patch adds two very simple psql commands: \quit_if and \quit_unless. A few comments about the feature design: I'm unsure about the name, esp with '_'. There are some \lo_* commands, but others rely on pasted words (\crosstabview, \errverbose, ...). I'm wondering if an

Re: [HACKERS] psql autocomplete works not good in USER command in 9.6

On Thu, Oct 6, 2016 at 9:17 PM, Дмитрий Воронин wrote: > I find, that autocomplete does not works good when I type in psql some USER > commands: > > CREATE USER ... > ALTER USER ... > > psql's autocomplete returns database users and "pg_signal_backend" function, > I

Re: [HACKERS] psql casts aspersions on server reliability

On 28/09/16 17:13, David Steele wrote: > On 9/28/16 10:22 AM, Robert Haas wrote: >> On Wed, Sep 28, 2016 at 9:14 AM, Tom Lane wrote: >>> Robert Haas writes: psql tends to do things like this: rhaas=# select * from pg_stat_activity; FATAL:

Re: [HACKERS] psql casts aspersions on server reliability

On 9/28/16 10:22 AM, Robert Haas wrote: > On Wed, Sep 28, 2016 at 9:14 AM, Tom Lane wrote: >> Robert Haas writes: >>> psql tends to do things like this: >>> rhaas=# select * from pg_stat_activity; >>> FATAL: terminating connection due to administrator

Re: [HACKERS] psql casts aspersions on server reliability

On Wed, Sep 28, 2016 at 9:14 AM, Tom Lane wrote: > Robert Haas writes: >> psql tends to do things like this: >> rhaas=# select * from pg_stat_activity; >> FATAL: terminating connection due to administrator command >> server closed the connection

Re: [HACKERS] psql casts aspersions on server reliability

Robert Haas writes: > psql tends to do things like this: > rhaas=# select * from pg_stat_activity; > FATAL: terminating connection due to administrator command > server closed the connection unexpectedly > This probably means the server terminated abnormally >

Re: [HACKERS] psql: tab completion for \l

Gerdan Santos writes: > I did some tests and found nothing special. The stated resource is > implemented correctly. > He passes all regression tests and enables the use of the new features > specified. > The new status of this patch is: Ready for Committer Pushed, thanks.

Re: [HACKERS] psql: tab completion for \l

Hi On 8/17/16 2:41 PM, Gerdan Santos wrote: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation:tested, passed > > I

Re: [HACKERS] psql: tab completion for \l

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed I did some tests and found nothing special. The stated

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

On 4 May 2016 at 13:23, Peter Eisentraut wrote: > On 5/4/16 3:21 AM, Dean Rasheed wrote: >> Well, appendStringLiteralAH() takes both, so that sets a precedent. > Works for me. Could you supply an updated patch with a static function > instead of a macro? Then I

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

On 5/4/16 3:21 AM, Dean Rasheed wrote: Well, appendStringLiteralAH() takes both, so that sets a precedent. Works for me. Could you supply an updated patch with a static function instead of a macro? Then I think this is good to go. (bonus points for some tests) -- Peter Eisentraut

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

On 4 May 2016 at 01:35, Peter Eisentraut wrote: > On 5/3/16 3:10 PM, Dean Rasheed wrote: >> On 3 May 2016 at 16:52, Peter Eisentraut >>> >>> I would change appendReloptionsArrayAH() to a function and keep AH as the >>> first argument (similar to other functions

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

On 5/3/16 3:10 PM, Dean Rasheed wrote: On 3 May 2016 at 16:52, Peter Eisentraut wrote: I would change appendReloptionsArrayAH() to a function and keep AH as the first argument (similar to other functions that take such a handle). I can understand changing

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

On 3 May 2016 at 16:52, Peter Eisentraut wrote: > I would change appendReloptionsArrayAH() to a function and keep AH as the > first argument (similar to other functions that take such a handle). I can understand changing it to a function, but I don't think AH

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

On 5/2/16 8:53 AM, Dean Rasheed wrote: Here are updated patches doing that --- the first moves fmtReloptionsArray() from pg_dump.c to fe_utils/string_utils.c so that it can be shared by pg_dump and psql, and renames it to appendReloptionsArray(). The second patch fixes the actual psql bug.

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

On 27 April 2016 at 08:36, Dean Rasheed wrote: > Here is a rough patch based on the way pg_dump handles this. It still > needs a bit of polishing -- in particular I think fmtReloptionsArray() > (copied from pg_dump) should probably be moved to string_utils.c so > that it

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

[Looking back over old threads] On 22 July 2015 at 22:00, Dean Rasheed wrote: > This appears to be missing support for view options (WITH CHECK OPTION > and security_barrier), so editing a view with either of those options > will cause them to be stripped off. It seems

Re: [HACKERS] psql metaqueries with \gexec

On Mon, Apr 4, 2016 at 3:31 PM, Tom Lane wrote: > Corey Huinker writes: > > Patch attached. Changes are thus: > > - rebased > > - pset.gexec_flag unconditionally set to false at end of SendQuery > > - wording of documentation describing execution

Re: [HACKERS] psql metaqueries with \gexec

Corey Huinker writes: > Patch attached. Changes are thus: > - rebased > - pset.gexec_flag unconditionally set to false at end of SendQuery > - wording of documentation describing execution order of results > - rebasing allowed for undoing the re-wrap of enumerated slash

Re: [HACKERS] psql metaqueries with \gexec

On Sun, Apr 3, 2016 at 8:42 PM, Corey Huinker wrote: > On Sun, Apr 3, 2016 at 7:43 PM, Tom Lane wrote: > >> Corey Huinker writes: >> >>> + The secondary queries are executed in top-to-bottom, >> >>> left-to-right

Re: [HACKERS] psql metaqueries with \gexec

On Sun, Apr 3, 2016 at 7:43 PM, Tom Lane wrote: > Corey Huinker writes: > >>> + The secondary queries are executed in top-to-bottom, > >>> left-to-right order, so the command > > >> I took that as meaning what I said above. > > > Would using

Re: [HACKERS] psql metaqueries with \gexec

Corey Huinker writes: >>> + The secondary queries are executed in top-to-bottom, >>> left-to-right order, so the command >> I took that as meaning what I said above. > Would using the term https://en.wikipedia.org/wiki/Row-major_order be more > clear? Meh, I

Re: [HACKERS] psql metaqueries with \gexec

> > + The secondary queries are executed in top-to-bottom, > left-to-right order, so the command > > I took that as meaning what I said above. > > Would using the term https://en.wikipedia.org/wiki/Row-major_order be more clear? The secondary queries are executed in row-major order,

Re: [HACKERS] psql metaqueries with \gexec

Corey Huinker writes: > On Sun, Apr 3, 2016 at 4:26 PM, Tom Lane wrote: >> I'm not Jim, but I have a question: what's the motivation for the >> Fortran-order traversal of the result (down rows before across columns)? > If I am understanding you

Re: [HACKERS] psql metaqueries with \gexec

On Sun, Apr 3, 2016 at 4:26 PM, Tom Lane wrote: > Robert Haas writes: > > Jim, can you re-review this? > > I'm not Jim, but I have a question: what's the motivation for the > Fortran-order traversal of the result (down rows before across columns)? > It

Re: [HACKERS] psql metaqueries with \gexec

Robert Haas writes: > Jim, can you re-review this? I'm not Jim, but I have a question: what's the motivation for the Fortran-order traversal of the result (down rows before across columns)? It seems less than intuitive to do it that way. Perhaps there's a good reason, but

Re: [HACKERS] psql metaqueries with \gexec

On Mon, Mar 14, 2016 at 7:54 AM, Corey Huinker wrote: > Patch attached. Changes are thus: > - proper assignment of success var > - added documentation to psql manpage/html with examples pulled from > regression tests. > > Not changed are: > - exuberant braces, can remove

Re: [HACKERS] psql metaqueries with \gexec

> > > I'm getting a warning from this patch: > > 1 warning generated. > Fixed that one. (note that I'm using CC='ccache clang -Qunused-arguments > -fcolor-diagnostics') > > for (r = 0; r < nrows; r++) >> { >> for (c = 0; c < ncolumns; c++) >> { >>

Re: [HACKERS] psql metaqueries with \gexec

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Still needs documentation. The new status of this patch is: Waiting

Re: [HACKERS] psql metaqueries with \gexec

On 2/22/16 1:01 PM, Corey Huinker wrote: In the mean time, update patch attached. Really attached this time. I'm getting a warning from this patch: common.c:947:8: warning: variable 'success' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]

Re: [HACKERS] psql completion for ids in multibyte string

Hello, At Mon, 7 Mar 2016 12:34:15 -0500, Robert Haas wrote in > >> Fix pushed. > > > > Thank you for committing this. I can see only one commit for this > > in the repository but I believe it is the

Re: [HACKERS] psql completion for ids in multibyte string

On Sun, Mar 6, 2016 at 11:24 PM, Kyotaro HORIGUCHI wrote: > At Fri, 4 Mar 2016 12:30:17 -0500, Robert Haas wrote > in >> >>> I committed this and back-patched this but

Re: [HACKERS] psql completion for ids in multibyte string

At Fri, 4 Mar 2016 12:30:17 -0500, Robert Haas wrote in > >>> I committed this and back-patched this but (1) I avoided changing the > >>> other functions for now and (2) I gave both the byte length and

Re: [HACKERS] psql completion for ids in multibyte string

On Fri, Mar 4, 2016 at 12:08 PM, Robert Haas wrote: > On Fri, Mar 4, 2016 at 12:02 PM, Alvaro Herrera > wrote: >> Robert Haas wrote: >>> On Wed, Mar 2, 2016 at 8:07 PM, Kyotaro HORIGUCHI >>> wrote: >>> > Hello,

Re: [HACKERS] psql completion for ids in multibyte string

Robert Haas wrote: > On Wed, Mar 2, 2016 at 8:07 PM, Kyotaro HORIGUCHI > wrote: > > Hello, thank you for the comments. > >> I think we should leave string_length as it is and use a new variable > >> for character-based length, as in the attached. > > > > Basically

<    1   2   3   4   5   6   7   8   9   10   >