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