Re: psql - better support pipe line
От | Jim Nasby |
---|---|
Тема | Re: psql - better support pipe line |
Дата | |
Msg-id | 55E0BBF0.7090600@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: psql - better support pipe line ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>) |
Ответы |
Re: psql - better support pipe line
|
Список | pgsql-hackers |
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 and do whatever you want with it at > that point, including format it to a connection URI. > > > Hm... but that would mean that suddenly psql would need JSON parsing > capabilities and URI escaping code would have to be moved there too? So > every client that links to libpq and wants to use this feature going as > far as reconstructing an URI would need both of the capabilities. Anything that's doing this presumably has connected to the database, which on any recent version means you have plenty of ability to process JSON at the SQL layer. > Why instead of JSON not spit conninfo format, with proper escaping? > That could be a separate library call, e.g. PGgetConnectionString() and > a separate backslash command: \conninfo Do you mean as a URI? The downside to that it's it's more difficult to parse than JSON. Another option might be an array. 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. All that said, the patch already adds significant value and you could always parse the URI if you really needed to. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: