Re: [HACKERS] psql - better support pipe line

2015-08-29 Thread Shulgin, Oleksandr
On Fri, Aug 28, 2015 at 9:52 PM, Jim Nasby jim.na...@bluetreble.com wrote: On 8/28/15 3:58 AM, Shulgin, Oleksandr wrote: It occurs to me the most flexible thing that could be done here would be providing a libpq function that spits out JSON connection parameters and have psql

Re: [HACKERS] psql - better support pipe line

2015-08-29 Thread Jim Nasby
On 8/29/15 8:10 AM, Shulgin, Oleksandr wrote: The other issue is there's no way to capture \conninfo inside of psql and do something with it. If instead this was exposed as a variable, you could handle it in SQL if you wanted to. Yeah, I forgot about the variable proposal, that

Re: [HACKERS] psql - better support pipe line

2015-08-28 Thread Shulgin, Oleksandr
On Fri, Aug 28, 2015 at 3:29 AM, Jim Nasby jim.na...@bluetreble.com wrote: On 8/27/15 8:37 AM, Pavel Stehule wrote: I don't think we can detect and remove the default values from this output in a reliable way? This is pretty difficult - any parameter can be important, and hard to

Re: [HACKERS] psql - better support pipe line

2015-08-28 Thread Jim Nasby
On 8/28/15 3:58 AM, Shulgin, Oleksandr wrote: It occurs to me the most flexible thing that could be done here would be providing a libpq function that spits out JSON connection parameters and have psql turn that into a variable. It would be easy to feed that to a SQL statement

Re: [HACKERS] psql - better support pipe line

2015-08-27 Thread Pavel Stehule
2015-08-27 11:54 GMT+02:00 Shulgin, Oleksandr oleksandr.shul...@zalando.de : On Wed, Aug 26, 2015 at 5:44 PM, Pavel Stehule pavel.steh...@gmail.com wrote: Hi 2015-08-25 17:21 GMT+02:00 Tom Lane t...@sss.pgh.pa.us: Jim Nasby jim.na...@bluetreble.com writes: What I've had problems with

Re: [HACKERS] psql - better support pipe line

2015-08-27 Thread Pavel Stehule
2015-08-27 11:54 GMT+02:00 Shulgin, Oleksandr oleksandr.shul...@zalando.de : On Wed, Aug 26, 2015 at 5:44 PM, Pavel Stehule pavel.steh...@gmail.com wrote: Hi 2015-08-25 17:21 GMT+02:00 Tom Lane t...@sss.pgh.pa.us: Jim Nasby jim.na...@bluetreble.com writes: What I've had problems with

Re: [HACKERS] psql - better support pipe line

2015-08-27 Thread Jim Nasby
On 8/27/15 8:37 AM, Pavel Stehule wrote: I don't think we can detect and remove the default values from this output in a reliable way? This is pretty difficult - any parameter can be important, and hard to identify default values on client side without connect to server side. I don't

Re: [HACKERS] psql - better support pipe line

2015-08-27 Thread Shulgin, Oleksandr
On Wed, Aug 26, 2015 at 5:44 PM, Pavel Stehule pavel.steh...@gmail.com wrote: Hi 2015-08-25 17:21 GMT+02:00 Tom Lane t...@sss.pgh.pa.us: Jim Nasby jim.na...@bluetreble.com writes: What I've had problems with is trying to correlate psql specified connection attributes with things like

Re: [HACKERS] psql - better support pipe line

2015-08-26 Thread Pavel Stehule
Hi 2015-08-25 17:21 GMT+02:00 Tom Lane t...@sss.pgh.pa.us: Jim Nasby jim.na...@bluetreble.com writes: What I've had problems with is trying to correlate psql specified connection attributes with things like DBI. It would be nice if there was a way to get a fully formed connection URI for

Re: [HACKERS] psql - better support pipe line

2015-08-25 Thread Jim Nasby
On 8/24/15 3:04 PM, Pavel Stehule wrote: (1) there is no reason to believe that the db name and only the db name is needed to do another connection; what about port, host, user, etc? I have to agree - the possibilities is much more than database name - so one option is not good idea.

Re: [HACKERS] psql - better support pipe line

2015-08-25 Thread Tom Lane
Jim Nasby jim.na...@bluetreble.com writes: What I've had problems with is trying to correlate psql specified connection attributes with things like DBI. It would be nice if there was a way to get a fully formed connection URI for the current connection. Yeah, although I'd think the

Re: [HACKERS] psql - better support pipe line

2015-08-24 Thread Tom Lane
Heikki Linnakangas hlinn...@iki.fi writes: On 08/24/2015 08:06 AM, Pavel Stehule wrote: it works perfectly - but the line xargs -P 3 -I % sh -c psql % -q -c 'analyze pg_attribute'; echo % is little bit ugly - with some psql option it can be cleaned to xargs -P3 -I % psql % -q --echo-db -c

Re: [HACKERS] psql - better support pipe line

2015-08-24 Thread Andrew Dunstan
On 08/24/2015 06:49 AM, Heikki Linnakangas wrote: On 08/24/2015 08:06 AM, Pavel Stehule wrote: Hi I found so a set psql and xargs is pretty strong. But I miss a psql option for simple returning current database and continuing in pipeline. What I am doing: psql postgres -At -c select

Re: [HACKERS] psql - better support pipe line

2015-08-24 Thread Heikki Linnakangas
On 08/24/2015 08:06 AM, Pavel Stehule wrote: Hi I found so a set psql and xargs is pretty strong. But I miss a psql option for simple returning current database and continuing in pipeline. What I am doing: psql postgres -At -c select datname from pg_database | xargs -P 3 -I % psql % -At -c

Re: [HACKERS] psql - better support pipe line

2015-08-24 Thread Pavel Stehule
2015-08-24 12:49 GMT+02:00 Heikki Linnakangas hlinn...@iki.fi: On 08/24/2015 08:06 AM, Pavel Stehule wrote: Hi I found so a set psql and xargs is pretty strong. But I miss a psql option for simple returning current database and continuing in pipeline. What I am doing: psql postgres -At

Re: [HACKERS] psql - better support pipe line

2015-08-24 Thread Pavel Stehule
2015-08-24 16:02 GMT+02:00 Tom Lane t...@sss.pgh.pa.us: Heikki Linnakangas hlinn...@iki.fi writes: On 08/24/2015 08:06 AM, Pavel Stehule wrote: it works perfectly - but the line xargs -P 3 -I % sh -c psql % -q -c 'analyze pg_attribute'; echo % is little bit ugly - with some psql option