Re: psql - better support pipe line

On Fri, Aug 28, 2015 at 9:52 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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 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.

*Cough*... Well, the fact that it's technically not impossible, doesn't
mean it's the right way to do it. By the same reasoning we can also ask
the server to calculate 1+1 for us in SQL. :-)

And that will work even with a 9.0 server, while parsing JSON -- not
really. Another point is that you don't need an *alive* connection to be
able to extract its URI/conninfo string, while when offloading JSON parsing
part to the server you suddenly do. Bottom line for me: while still
possible, this can't be portable.

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

Hm... actually why not just use the existing call:

PQconninfoOption *PQconninfo(PGconn *conn);

and move whatever code is needed to form an URI or conninfo string to psql
itself?

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 would be a more useful way
to expose it for sure.

--
Alex