Re: [HACKERS] Re: new set of psql patches for loading (saving) data from (to) text, binary files

2017-04-05 Thread Pavel Stehule
2017-04-06 3:34 GMT+02:00 Stephen Frost : > Andres, > > * Andres Freund (and...@anarazel.de) wrote: > > On 2017-04-05 21:07:59 -0400, Stephen Frost wrote: > > > * Andres Freund (and...@anarazel.de) wrote: > > > > I don't yet have a good idea how to deal with moving individual cells > > > > into fi

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

2017-04-05 Thread Pavel Stehule
2017-04-05 22:33 GMT+02:00 Andres Freund : > Hi, > > > I'd like some input from other committers whether we want this. I'm > somewhat doubtful, but don't have particularly strong feelings. > > > > + > > + > > + Block level PRAGMA > > + > > + > > +PRAGMA > > +in PL/pgSQL > > + >

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

2017-04-05 Thread Pavel Stehule
2017-04-05 23:22 GMT+02:00 Tom Lane : > Andres Freund writes: > > I'd like some input from other committers whether we want this. I'm > > somewhat doubtful, but don't have particularly strong feelings. > > I don't really want to expose the workings of the plancache at user level. > The heuristic

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

2017-04-05 Thread Pavel Stehule
> > That echoes my perception - so let's move this to the next CF? It's not > like this patch has been pending for very long. > sure Regards Pavel > > - Andres >

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

2017-04-05 Thread Pavel Stehule
2017-04-06 8:08 GMT+02:00 Pavel Stehule : > > > 2017-04-05 23:22 GMT+02:00 Tom Lane : > >> Andres Freund writes: >> > I'd like some input from other committers whether we want this. I'm >> > somewhat doubtful, but don't have particularly stron

Re: [HACKERS] Re: new set of psql patches for loading (saving) data from (to) text, binary files

2017-04-06 Thread Pavel Stehule
2017-04-06 14:47 GMT+02:00 Stephen Frost : > Greetings, > > * Pavel Stehule (pavel.steh...@gmail.com) wrote: > > 2017-04-06 3:34 GMT+02:00 Stephen Frost : > > > Having the template not require the row/column place-holders included > > > strikes me as more li

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

2017-04-06 Thread Pavel Stehule
2017-04-06 12:30 GMT+02:00 Andrew Dunstan : > > > On 04/05/2017 05:41 PM, Andres Freund wrote: > > On 2017-04-05 17:22:34 -0400, Tom Lane wrote: > >> Andres Freund writes: > >>> I'd like some input from other committers whether we want this. I'm > >>> somewhat doubtful, but don't have particular

Re: [HACKERS] Undefined psql variables

2017-04-07 Thread Pavel Stehule
2017-04-07 9:52 GMT+02:00 Fabien COELHO : > > Hello Corey, > > \if defined varname \if sql boolean expression to send to server \if compare value operator value >>> >>> I'm still thinking:-) >>> >>> Independently of the my aethetical complaint against having

Re: [HACKERS] Undefined psql variables

2017-04-07 Thread Pavel Stehule
2017-04-07 21:04 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > I wish I could have an explanation about why the :?varname (or some other >>> variant) syntax I suggested has a "namespace" issue. >>> >>> The advantage that I see is that although it is obviously ugly, it is >>> ugly >>> in the conti

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

2017-04-08 Thread Pavel Stehule
2017-04-08 2:30 GMT+02:00 Peter Eisentraut : > On 4/6/17 14:32, Pavel Stehule wrote: > > I like to see any proposals about syntax or implementation. > > > > Using PRAGMA is one variant - introduced by PLpgSQL origin - Ada > > language. The PRAGMA syntax can be used for

Re: [HACKERS] Undefined psql variables

2017-04-08 Thread Pavel Stehule
2017-04-08 12:25 GMT+02:00 Fabien COELHO : > > Hello Pavel, > n > >> you proposal disallow client side expressions. >> > > I do agree that some client side expressions are necessary. I do not want > to disallow them. > > I agree so is not possible to mix server side and client side expressions. >>

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-10 Thread Pavel Stehule
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

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-10 Thread Pavel Stehule
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

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-10 Thread Pavel Stehule
> > \else > \if :somevar > 1 and SERVER_NUM >= 10 > should be \if :somevar > 1 and :SERVER_NUM >= 10 > ... > \end > >

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-11 Thread Pavel Stehule
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

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-11 Thread Pavel Stehule
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

Re: [HACKERS] Undefined psql variables

2017-04-12 Thread Pavel Stehule
2017-04-12 17:05 GMT+02:00 Robert Haas : > On Sun, Apr 2, 2017 at 3:56 PM, Tom Lane wrote: > > So my view of this is that "send the expression to the server" ought > > to be just one option for \if, not the only way to do it. > > I heartily agree. There should be some kind of client-side express

Re: [HACKERS] bugfix: xpath encoding issue

2017-04-13 Thread Pavel Stehule
2017-04-13 17:19 GMT+02:00 Alvaro Herrera : > Pavel Stehule wrote: > > Hi > > > > When I tested XMLTABLE function I found a bug of XPATH function - > > xpath_internal > > > > There xmltype is not correctly encoded to xmlChar due possible invalid > >

Re: [HACKERS] Undefined psql variables

2017-04-13 Thread Pavel Stehule
> > > 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 checked the pgbench code - and I think it can work well - just add logical operators and compare operators. Don't need to create more c

Re: [HACKERS] Undefined psql variables

2017-04-13 Thread Pavel Stehule
2017-04-13 19:46 GMT+02:00 Corey Huinker : > >> > 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

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-16 Thread Pavel Stehule
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

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-16 Thread Pavel Stehule
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

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-17 Thread Pavel Stehule
> > > 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

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-17 Thread Pavel Stehule
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

Re: [HACKERS] type cache for concat functions

2017-06-17 Thread Pavel Stehule
2017-06-18 0:50 GMT+02:00 Dmitry Dolgov <9erthali...@gmail.com>: > > On 20 May 2017 at 10:03, Pavel Stehule wrote: > > > > Now concat is 2x times slower than || operator. With cached FmgrInfo for > > output function it will be only 5%. > > Looks nice and doe

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-06-18 Thread Pavel Stehule
2017-06-17 7:58 GMT+02:00 Fabien COELHO : > > I have not any other comments. The implementation is trivial. I rerun all >> tests and tests passed. >> >> I'll mark this patch as ready for commiters. >> > > Oops, I just noticed a stupid confusion on my part which got through, I > was setting "ERROR"

Re: [HACKERS] proposal psql \gdesc

2017-06-18 Thread Pavel Stehule
2017-06-16 8:45 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > new update - rebase, changed message >> > > I did yet another rebase of your patch after Tom alphabetically ordered > backslash commands. Here is the result. It looks well Thank you Pavel > > > -- > Fabien.

Re: [HACKERS] Optional message to user when terminating/cancelling backend

2017-06-19 Thread Pavel Stehule
2017-06-19 20:24 GMT+02:00 Daniel Gustafsson : > When terminating, or cancelling, a backend it’s currently not possible to > let > the signalled session know *why* it was dropped. This has nagged me in the > past and now it happened to come up again, so I took a stab at this. The > attached patc

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-06-27 Thread Pavel Stehule
Hi 2017-06-19 5:55 GMT+02:00 Pavel Stehule : > > > 2017-06-17 7:58 GMT+02:00 Fabien COELHO : > >> >> I have not any other comments. The implementation is trivial. I rerun all >>> tests and tests passed. >>> >>> I'll mark this patch as read

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-06-27 Thread Pavel Stehule
2017-06-27 17:30 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > We can introduce macro SetVariableBool(vars, varname, bool) instead >>> >>> SetVariable(pset.vars, "ERROR", "FALSE"); >>> >> >> I checked source code, and it requires little bit more harder refactoring >> because now we have SetVaria

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-06-28 Thread Pavel Stehule
2017-06-28 9:25 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > I agree that the existing "SetVariableBool" function is a misnommer, it >>> should be "SetVariableOn" given what it does, and it is not what we need. >>> >> >> switching default setting from ON to TRUE requires wider discussion - >> >

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-06-28 Thread Pavel Stehule
2017-06-28 10:04 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > + if (success) >> + { >> + char *ntuples = PQcmdTuples(results); >> + SetVariable(pset.vars, "ROW_COUNT", *ntuples ? ntuples : "0"); >> + SetVariable(pset.vars, "ERROR", "FALSE"); >> + } >> + else >> + { >> + SetVariable(pset.vars,

Re: [HACKERS] Parallel COPY FROM execution

2017-06-30 Thread Pavel Stehule
2017-06-30 14:23 GMT+02:00 Alex K : > Greetings pgsql-hackers, > > I am a GSOC student this year, my initial proposal has been discussed > in the following thread > https://www.postgresql.org/message-id/flat/7179F2FD-49CE- > 4093-AE14-1B26C5DFB0DA%40gmail.com > > Patch with COPY FROM errors handli

Re: [HACKERS] Parallel COPY FROM execution

2017-06-30 Thread Pavel Stehule
2017-06-30 15:42 GMT+02:00 Alex K : > On Fri, Jun 30, 2017 at 3:35 PM, Pavel Stehule > wrote: > > > > > > 2017-06-30 14:23 GMT+02:00 Alex K : > >> > >> Thus, it results in a ~60% performance boost per each x2 multiplication > of > >> pa

Re: [HACKERS] Parallel COPY FROM execution

2017-06-30 Thread Pavel Stehule
2017-06-30 15:45 GMT+02:00 Pavel Stehule : > > > 2017-06-30 15:42 GMT+02:00 Alex K : > >> On Fri, Jun 30, 2017 at 3:35 PM, Pavel Stehule >> wrote: >> > >> > >> > 2017-06-30 14:23 GMT+02:00 Alex K : >> >> >> >> Th

[HACKERS] proposal: psql: check env variable PSQL_PAGER

2017-07-25 Thread Pavel Stehule
Hi I wrote a special pager for psql. Surely, this pager is not good for paging of man pages. So is not good to set it as global pager. We can introduce new env variable PSQL_PAGER for this purpose. It can work similar like PSQL_EDITOR variable. Notes, comments? Regards Pavel

Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities

2017-07-26 Thread Pavel Stehule
2017-07-26 15:27 GMT+02:00 Robert Haas : > On Wed, Jun 21, 2017 at 10:01 AM, Remi Colinet > wrote: > > test=# SELECT pid, ppid, bid, concat(repeat(' ', 3 * indent),name), > value, > > unit FROM pg_progress(0,0); > > pid | ppid | bid | concat | value | unit > > ---+--

[HACKERS] tab complete for psql pset pager values

2017-07-26 Thread Pavel Stehule
Hi attached trivial patch for missing tab complete for \pset pager setting Regards Pavel diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c index e9fdc908c7..1b15c5b0d1 100644 --- a/src/bin/psql/tab-complete.c +++ b/src/bin/psql/tab-complete.c @@ -3536,6 +3536,8 @@ psql_compl

Re: [HACKERS] proposal: psql: check env variable PSQL_PAGER

2017-07-26 Thread Pavel Stehule
Hi 2017-07-26 13:15 GMT+02:00 Dagfinn Ilmari Mannsåker : > Pavel Stehule writes: > > > Hi > > > > I wrote a special pager for psql. Surely, this pager is not good for > paging > > of man pages. So is not good to set it as global pager. We can introduce > &g

Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities

2017-07-31 Thread Pavel Stehule
2017-07-31 11:09 GMT+02:00 Remi Colinet : > > > 2017-07-26 15:27 GMT+02:00 Robert Haas : > >> On Wed, Jun 21, 2017 at 10:01 AM, Remi Colinet >> wrote: >> > test=# SELECT pid, ppid, bid, concat(repeat(' ', 3 * indent),name), >> value, >> > unit FROM pg_progress(0,0); >> > pid | ppid | bid |

Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities

2017-08-01 Thread Pavel Stehule
ot;: 34, + > "blocks fetched": 18436,+ > "blocks total": 83334, + > "blocks percent": 22,

Re: [HACKERS] xmltable SQL conformance

2017-08-03 Thread Pavel Stehule
2017-08-03 22:14 GMT+02:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > I'm looking to update the SQL conformance list for the release. I'm > wondering whether the new xmltable feature fully completes the following > items: > > X300XMLTable > X301XMLTable: derived column list o

Re: [HACKERS] xmltable SQL conformance

2017-08-03 Thread Pavel Stehule
2017-08-03 22:54 GMT+02:00 Pavel Stehule : > > > 2017-08-03 22:14 GMT+02:00 Peter Eisentraut com>: > >> I'm looking to update the SQL conformance list for the release. I'm >> wondering whether the new xmltable feature fully completes the following >

Re: [HACKERS] xmltable SQL conformance

2017-08-07 Thread Pavel Stehule
2017-08-07 20:36 GMT+02:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 8/3/17 17:07, Pavel Stehule wrote: > > I'm looking to update the SQL conformance list for the release. > I'm > > wondering whether the new xm

Re: [HACKERS] pgbench - allow to store select results into variables

2017-08-13 Thread Pavel Stehule
Hi 2017-08-13 20:33 GMT+02:00 Fabien COELHO : > > Here is a v11. > > It is basically a simple rebase after Tom committed the "pgbench -M order" > patch. It interfered because the compound command management also needs > to delay part of the SQL command initialization. Some patch are luckier > tha

Re: [HACKERS] proposal: psql: check env variable PSQL_PAGER

2017-08-16 Thread Pavel Stehule
Hi 2017-08-16 6:58 GMT+02:00 Thomas Munro : > On Thu, Jul 27, 2017 at 4:19 AM, Pavel Stehule > wrote: > > here is a patch - it is trivial > > The feature makes sense, follows an existing example (PSQL_EDITOR), > and works nicely. > >is platform-dependen

Re: [HACKERS] proposal: psql: check env variable PSQL_PAGER

2017-08-16 Thread Pavel Stehule
2017-08-16 12:47 GMT+02:00 Thomas Munro : > On Wed, Aug 16, 2017 at 9:56 PM, Pavel Stehule > wrote: > > 2017-08-16 6:58 GMT+02:00 Thomas Munro : > >> Stray blank line. > > > > I am not sure if I see last issue well. > > I meant this: > > >

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

2017-08-16 Thread Pavel Stehule
Hi 2017-08-15 4:37 GMT+02:00 Peter Eisentraut : > On 3/11/17 07:06, Pavel Stehule wrote: > > I am sending a updated version with separated sort direction in special > > variable > > This patch also needs a rebase. > I am sending rebased patch Regards Pavel &

Re: [HACKERS] HISTIGNORE for psql

2017-08-17 Thread Pavel Stehule
2017-08-17 9:23 GMT+02:00 Vesa-Matti J Kari : > > Hello, > > Bash has HISTIGNORE feature that allows you to exclude certain commands > from the command history (e.g. shutdown, reboot, rm *). > > Would it make any sense to add such a feature to psql (e.g. to ignore > DROP, DELETE commands)? > It i

Re: [HACKERS] possible encoding issues with libxml2 functions

2017-08-18 Thread Pavel Stehule
Hi 2017-08-08 2:10 GMT+02:00 Noah Misch : > On Wed, Apr 05, 2017 at 10:53:39PM +0200, Pavel Stehule wrote: > > 2017-03-17 4:23 GMT+01:00 Noah Misch : > > > On Sun, Mar 12, 2017 at 10:26:33PM +0100, Pavel Stehule wrote: > > > > 2017-03-12 21:57 GMT+01:00 Noah Mi

Re: [HACKERS] possible encoding issues with libxml2 functions

2017-08-19 Thread Pavel Stehule
> > Isn't the most correct solution to call xml_parse function? > I am reply to self. Probably not. Now, I am thinking so I found a reason of this issue. The document processed in xpath_internal is passed to libXML2 by doc = xmlCtxtReadMemory(ctxt, (char *) string, len, NULL, NULL, 0); We d

Re: [HACKERS] possible encoding issues with libxml2 functions

2017-08-19 Thread Pavel Stehule
Hi I am sending some POC - it does support XPATH and XMLTABLE for not UTF8 server encoding. In this case, all strings should be converted to UTF8 before call libXML2 functions, and result should be converted back from UTF8. I found some previous experiments https://marc.info/?l=pgsql-bug s&m=12

Re: [HACKERS] possible encoding issues with libxml2 functions

2017-08-19 Thread Pavel Stehule
Hi 2017-08-19 22:53 GMT+02:00 Pavel Stehule : > Hi > > I am sending some POC - it does support XPATH and XMLTABLE for not UTF8 > server encoding. > > In this case, all strings should be converted to UTF8 before call libXML2 > functions, and result should be converted back f

Re: [HACKERS] possible encoding issues with libxml2 functions

2017-08-19 Thread Pavel Stehule
2017-08-20 4:17 GMT+02:00 Noah Misch : > On Fri, Aug 18, 2017 at 11:43:19PM +0200, Pavel Stehule wrote: > > yes, probably libXML2 try to do check from utf8 encoding to header > > specified encoding. > > Yes. That has been the topic of this thread. > > > a) all valu

Re: [HACKERS] possible encoding issues with libxml2 functions

2017-08-20 Thread Pavel Stehule
2017-08-20 9:21 GMT+02:00 Noah Misch : > On Sun, Aug 20, 2017 at 08:46:03AM +0200, Pavel Stehule wrote: > > 2017-08-20 4:17 GMT+02:00 Noah Misch : > > > On Sat, Aug 19, 2017 at 10:53:19PM +0200, Pavel Stehule wrote: > > > > I am sending some POC - it does supp

Re: [HACKERS] possible encoding issues with libxml2 functions

2017-08-20 Thread Pavel Stehule
Hi > xpath-bugfix.patch affected only xml values containing an xml declaration > with > "encoding" attribute. In UTF8 databases, this latest proposal > (xpath-parsing-error-fix.patch) is equivalent to xpath-bugfix.patch. In > non-UTF8 databases, xpath-parsing-error-fix.patch affects all xml val

Re: [HACKERS] possible encoding issues with libxml2 functions

2017-08-20 Thread Pavel Stehule
> > xpath-bugfix.patch affected only xml values containing an xml declaration > with > "encoding" attribute. In UTF8 databases, this latest proposal > (xpath-parsing-error-fix.patch) is equivalent to xpath-bugfix.patch. In > non-UTF8 databases, xpath-parsing-error-fix.patch affects all xml values

Re: [HACKERS] WITH clause in CREATE STATISTICS

2017-04-22 Thread Pavel Stehule
2017-04-22 11:30 GMT+02:00 Simon Riggs : > On 21 April 2017 at 01:21, Tomas Vondra > wrote: > > On 04/21/2017 12:13 AM, Tom Lane wrote: > >> > >> Alvaro Herrera writes: > >>> > >>> Simon just pointed out that having the WITH clause appear in the middle > >>> of the CREATE STATISTICS command look

Re: [HACKERS] Cached plans and statement generalization

2017-04-26 Thread Pavel Stehule
2017-04-26 12:30 GMT+02:00 Konstantin Knizhnik : > > > On 26.04.2017 10:49, Konstantin Knizhnik wrote: > > > > On 26.04.2017 04:00, Tsunakawa, Takayuki wrote: Are you considering some > upper limit on the number of prepared statements? > In this case we need some kind of LRU for maintaining cach

[HACKERS] proposal psql \gdesc

2017-04-27 Thread Pavel Stehule
Hi Sometimes I have to solve the result types of some query. It is invisible in psql. You have to materialize table or you have to create view. Now, when we can enhance \g command, we can introduce query describing some like select a, b from foo \gdesc | type | length | collation | .

Re: [HACKERS] CTE inlining

2017-04-29 Thread Pavel Stehule
2017-04-30 6:28 GMT+02:00 Tom Lane : > Craig Ringer writes: > > - as you noted, it is hard to decide when it's worth inlining vs > > materializing for CTE terms referenced more than once. > > [ raised eyebrow... ] Please explain why the answer isn't trivially > "never". > > There's already a pre

Re: [HACKERS] CTE inlining

2017-04-30 Thread Pavel Stehule
2017-05-01 1:21 GMT+02:00 Andres Freund : > On 2017-04-30 07:19:21 +0200, Pavel Stehule wrote: > > why we cannot to introduce GUC option - enable_cteoptfence ? > > Doesn't really solve the issue, and we've generally shied away from GUCs > that influence behaviour

Re: [HACKERS] proposal psql \gdesc

2017-05-02 Thread Pavel Stehule
2017-04-28 6:08 GMT+02:00 Pavel Stehule : > Hi > > Sometimes I have to solve the result types of some query. It is invisible > in psql. You have to materialize table or you have to create view. Now, > when we can enhance \g command, we can introduce query describing > > some

Re: [HACKERS] CTE inlining

2017-05-03 Thread Pavel Stehule
2017-05-03 18:54 GMT+02:00 David Fetter : > On Wed, May 03, 2017 at 01:27:38PM -0300, Claudio Freire wrote: > > On Wed, May 3, 2017 at 11:31 AM, David Fetter wrote: > > > Are you aware of such an ORM which both supports WITH and doesn't > > > also closely track PostgreSQL development? I'm not. >

Re: [HACKERS] CTE inlining

2017-05-03 Thread Pavel Stehule
2017-05-03 19:33 GMT+02:00 Alvaro Herrera : > David Fetter wrote: > > > When we add a "temporary" GUC, we're taking on a gigantic burden. > > Either we support it forever somehow, or we put it on a deprecation > > schedule immediately and expect to be answering questions about it for > > years aft

Re: [HACKERS] proposal psql \gdesc

2017-05-08 Thread Pavel Stehule
Hi 2017-05-08 9:08 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > A complement to my previous comments: > > Also, maybe it would be better if the statement is cleaned up server side >> at the end of the execution. Not sure how to achieve that, though, libpq >> seems to lack the relevant function:

Re: [HACKERS] proposal psql \gdesc

2017-05-08 Thread Pavel Stehule
2017-05-08 12:59 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > After giving it some thoughts, I see three possible solutions: >>> >>> 0. Do nothing about it. >>>I would prefer the prepare is cleaned up. >>> >>> 1. assign a special name, eg "_psql_gdesc_", so that >>>DEALLOCATE "_psql_gdes

Re: [HACKERS] proposal psql \gdesc

2017-05-09 Thread Pavel Stehule
Hi 2017-05-07 22:55 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > Sometimes I have to solve the result types of some query. It is invisible >>> in psql. >>> >> > Indeed. My 0.02€ about this patch: > > > About the feature: > > It looks useful to allow to show the resulting types of a query. > > >

[HACKERS] export import bytea from psql

2017-05-09 Thread Pavel Stehule
Hi This is topic, that I try to solve some longer time. I would to open discussion before summer commitfest. The work with binary data or long text fields (multilines) or long not only utf8 encoded XML is not well supported by psql console. Is not hard to use binary protocol and write custom appl

Re: [HACKERS] proposal psql \gdesc

2017-05-09 Thread Pavel Stehule
2017-05-09 18:15 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > Patch applies cleanly and compiles. >>> >> > Idem for v2. "make check" ok. Tests look good. > > I would suggest some rewording, maybe: >>> >>> "Show the description of the result of the current query buffer without >>> actually execut

Re: [HACKERS] proposal psql \gdesc

2017-05-09 Thread Pavel Stehule
2017-05-09 20:37 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > [...] it is little bit worse. I cannot to distinguish between SELECT\gdesc >> and TRUNCATE xxx\gdesc . All are valid commands and produce empty result, >> so result of \gdesc command should be empty result too. >> >> postgres=# trunca

Re: [HACKERS] proposal psql \gdesc

2017-05-09 Thread Pavel Stehule
2017-05-09 21:23 GMT+02:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 5/3/17 02:56, Pavel Stehule wrote: > > Sometimes I have to solve the result types of some query. It is > > invisible in psql. You have to materialize table or you have to > >

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

2017-05-10 Thread Pavel Stehule
Hi 2017-05-10 18:40 GMT+02:00 Remi Colinet : > Hello, > > This is version 2 of the new command name PROGRESS which I wrote in order > to monitor long running SQL queries in a Postgres backend process. > This patch introduce lot of reserved keyword. Why? It can breaks lot of applications. Cannot

Re: [HACKERS] export import bytea from psql

2017-05-10 Thread Pavel Stehule
2017-05-09 23:00 GMT+02:00 Daniel Verite : > Pavel Stehule wrote: > > > 1. using psql variables - we just need to write commands \setfrom > > \setfrombf - this should be very simple implementation. The value can be > > used more times. On second hand - the loaded

Re: [HACKERS] export import bytea from psql

2017-05-11 Thread Pavel Stehule
2017-05-11 17:16 GMT+02:00 Daniel Verite : > Pavel Stehule wrote: > > > It is similar to my first or second proposal - rejected by Tom :( > > Doesn't it differ? ISTM that in the patches/discussion related to: > https://commitfest.postgresql.org/11/787/ > it w

[HACKERS] proposal - using names as primary names of plpgsql function parameters instead $ based names

2017-05-13 Thread Pavel Stehule
Hi Now, I when I working on plpgsql_check, I have to check function parameters. I can use fn_vargargnos and out_param_varno for list of arguments and related varno(s). when I detect some issue, I am using refname. It is not too nice now, because these refnames are $ based. Long names are alias onl

[HACKERS] issue: record or row variable cannot be part of multiple-item INTO list

2017-05-13 Thread Pavel Stehule
Hi I am working on migration large Oracle application to Postgres. When I started migration procedures with OUT parameters I found following limit "record or row variable cannot be part of multiple-item INTO list" I checked code and it looks so this limit is not necessary for ROW types (what is

Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list

2017-05-13 Thread Pavel Stehule
2017-05-13 22:20 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > I am working on migration large Oracle application to Postgres. When I > > started migration procedures with OUT parameters I found following limit > > > "record or row variable cannot be part of mult

Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list

2017-05-14 Thread Pavel Stehule
2017-05-14 5:04 GMT+02:00 Pavel Stehule : > > > 2017-05-13 22:20 GMT+02:00 Tom Lane : > >> Pavel Stehule writes: >> > I am working on migration large Oracle application to Postgres. When I >> > started migration procedures with OUT parameters I found fo

[HACKERS] Re: proposal - using names as primary names of plpgsql function parameters instead $ based names

2017-05-15 Thread Pavel Stehule
2017-05-13 18:26 GMT+02:00 Pavel Stehule : > Hi > > Now, I when I working on plpgsql_check, I have to check function > parameters. I can use fn_vargargnos and out_param_varno for list of > arguments and related varno(s). when I detect some issue, I am using > refname. It i

Re: [HACKERS] proposal psql \gdesc

2017-05-15 Thread Pavel Stehule
2017-05-09 23:00 GMT+02:00 Fabien COELHO : > > What about detecting the empty result (eg PQntuples()==0?) and writing >>> "Empty result" instead of the strange looking empty table above? That >>> would >>> just mean skipping the PrintQueryResult call in this case? >>> >> >> PQntuples == 0 every ti

[HACKERS] zajimavy clanek - par vychytavek v pg

2017-05-18 Thread Pavel Stehule
Ahoj viz http://blog.cleverelephant.ca/2017/05/great-postgresql.html Pavel

Re: [HACKERS] Re: proposal - using names as primary names of plpgsql function parameters instead $ based names

2017-05-18 Thread Pavel Stehule
2017-05-19 3:14 GMT+02:00 Peter Eisentraut : > On 5/15/17 14:34, Pavel Stehule wrote: > > Now, I when I working on plpgsql_check, I have to check function > > parameters. I can use fn_vargargnos and out_param_varno for list of > > arguments and related varno(s

Re: [HACKERS] Re: proposal - using names as primary names of plpgsql function parameters instead $ based names

2017-05-19 Thread Pavel Stehule
2017-05-19 5:48 GMT+02:00 Pavel Stehule : > > > 2017-05-19 3:14 GMT+02:00 Peter Eisentraut com>: > >> On 5/15/17 14:34, Pavel Stehule wrote: >> > Now, I when I working on plpgsql_check, I have to check function >> > parameters. I can use fn_var

[HACKERS] type cache for concat functions

2017-05-20 Thread Pavel Stehule
Hi Now concat is 2x times slower than || operator. With cached FmgrInfo for output function it will be only 5%. Regards Pavel diff --git a/src/backend/utils/adt/varlena.c b/src/backend/utils/adt/varlena.c index be399f4..d3f04f8 100644 --- a/src/backend/utils/adt/varlena.c +++ b/src/backend/utils

Re: [HACKERS] proposal psql \gdesc

2017-05-20 Thread Pavel Stehule
Hi 2017-05-20 9:15 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > I am sending a variant with message instead empty result. >> > > Thanks. Patch looks good, applies, make check ok, code is neat. > > Personally I prefer empty result instead message. >> > > Hmm. I think that this version is less li

Re: [HACKERS] proposal psql \gdesc

2017-05-20 Thread Pavel Stehule
2017-05-20 22:26 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > - Maybe tests could also exercise unnamed columns, eg: >>> SELECT 1, 2, 3 \gdesc \g >>> >> >> done >> > > Can't see it. No big deal, but if you put it it did not get through, and > there is a warning with git apply on the very la

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-05-20 Thread Pavel Stehule
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

Re: [HACKERS] proposal psql \gdesc

2017-05-21 Thread Pavel Stehule
2017-05-21 8:39 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > v6 patch applies cleanly; make check ok; code, comments, doc & tests ok; > various interactive tests I did ok. > > Thanks for this useful little feature! > > Let's see what committers think about it. Thank you Pavel > > > -- > Fabi

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-05-21 Thread Pavel Stehule
Hi 2017-04-04 23:01 GMT+02:00 Pavel Stehule : > > > 2017-04-04 22:05 GMT+02:00 Fabien COELHO : > >> >> After some discussions about what could be useful since psql scripts now >> accepts tests, this patch sets a few variables which can be used by psql >> after

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-05-22 Thread Pavel Stehule
2017-05-22 9:40 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > After some discussions about what could be useful since psql scripts now accepts tests, this patch sets a few variables which can be used by psql after a "front door" (i.e. actually typed by the user) query: - RESU

Re: [HACKERS] psql - add special variable to reflect the last query status

2017-05-22 Thread Pavel Stehule
2017-05-22 21:33 GMT+02:00 Fabien COELHO : > > Please find attached a v2 which hopefully takes into account all your >>> points above. >>> >>> Open question: should it gather more PQerrorResultField, or the two >>> selected one are enough? If more, which should be included? >>> >> >> >> I don't th

Re: [HACKERS] pgbench more operators & functions

2017-05-23 Thread Pavel Stehule
Hi I am watching this patch - it looks so there are not problems. I found only issue in documentation - new CASE expression is not documented. Regards Pavel

Re: [HACKERS] pgbench more operators & functions

2017-05-29 Thread Pavel Stehule
2017-05-30 7:19 GMT+02:00 Fabien COELHO : > > [doc about CASE...] >>> >> >> I've improved it in attached v11: >> - add a link to the CASE full documentation >> - add an example expression with CASE ... >> > > Do you think I should improve the doc further? I am sorry, I didn't look there yet The

[HACKERS] proposal: PLpgSQL parallel assignemnt

2017-06-02 Thread Pavel Stehule
Hi Some modern or old languages (GO, Lua, CLU) has similarly designed function OUT parameters like PLpgSQL. In these languages is usually supported parallel assignment. It is not supported by PLpgSQL - there is workaround - using SELECT FROM, but it is workaround. The implementation of PA is triv

Re: [HACKERS] proposal: PLpgSQL parallel assignemnt

2017-06-02 Thread Pavel Stehule
2017-06-02 10:06 GMT+02:00 Craig Ringer : > On 2 June 2017 at 15:51, Pavel Stehule wrote: > > > a, b := fx(); > > > > Comments, notes, ideas? > > I'd be pretty happy to have > > (a, b) = (x, y); > (a, b) = f(x); > > which is SQL-esque. >

Re: [HACKERS] proposal: PLpgSQL parallel assignemnt

2017-06-02 Thread Pavel Stehule
2017-06-02 10:15 GMT+02:00 Pavel Stehule : > > > 2017-06-02 10:06 GMT+02:00 Craig Ringer : > >> On 2 June 2017 at 15:51, Pavel Stehule wrote: >> >> > a, b := fx(); >> > >> > Comments, notes, ideas? >> >> I'd be pretty happy

Re: [HACKERS] proposal: PLpgSQL parallel assignemnt

2017-06-02 Thread Pavel Stehule
2017-06-02 19:05 GMT+02:00 Pavel Stehule : > > > 2017-06-02 10:15 GMT+02:00 Pavel Stehule : > >> >> >> 2017-06-02 10:06 GMT+02:00 Craig Ringer : >> >>> On 2 June 2017 at 15:51, Pavel Stehule wrote: >>> >>> > a, b := fx(); >&

Re: [HACKERS] proposal psql \gdesc

2017-06-04 Thread Pavel Stehule
Hi 2017-06-04 10:47 GMT+02:00 Fabien COELHO : > > Hello Brent, > > Regarding the error message earlier >> > > 'No columns or command has no result', >> > > it might be clearer with the slightly longer >> > > 'The result has no columns or the command has no result'. >> > > I agree that a better ph

[HACKERS] strange error message from slave when connection to master cannot be established

2017-06-07 Thread Pavel Stehule
Hi I got strange error message - false message - max connection is less on slave than on master, although these numbers was same. The issue was in wrong connection string in recovery conf and slave cannot to check master and used some defaults. Regards Pavel

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