You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First off, I apologize if this isn't the right place for semi-random questions. Happy to go elsewhere if I'm off base here, not my intention at all to assume free help.
And why is that format reserved for connecting the native client only i.e. derived from the user's input connection config via pg package's Connection.getLibpqConnectionString?
So, just as you can input a connection URI e.g. new Client({ connectionString: 'postgresql://dbuser:secretpassword@localhost:5432/mydb' }),
would there be any value to allowing a user to configure a client with an equivalent key/val string e.g. something like new Client({ connectionString: "dbname=mydb user=dbuser password=secretpassword host=localhost port=5432" })?
I assume I'm still missing plenty here, but immediately, I can see the connection URI format feels maybe easier to write and, I assume, more familiar from other database engines e.g. mysql. Also, I know the key/val string format has rules for allowing spaces within identifiers and escaping that would further complicate writing in this format.
That said, if supporting this feature / "feature", more in the interest of theoretical completeness, would be even potentially useful, I'd be more than happy to contribute
Thanks for all the massive effort behind this tool; much appreciated!
The text was updated successfully, but these errors were encountered:
I assume I'm still missing plenty here, but immediately, I can see the connection URI format feels maybe easier to write and, I assume, more familiar from other database engines e.g. mysql. Also, I know the key/val string format has rules for allowing spaces within identifiers and escaping that would further complicate writing in this format.
That said, if supporting this feature / "feature", more in the interest of theoretical completeness, would be even potentially useful, I'd be more than happy to contribute
really good thoughts! You're right - it's just complexity to support that connection style & it's never really come up before. It's custom to postgres AFAIK, and writing text parsers is always a kinda edge case ridden footgun experience. Supporting the connection url is a more common pattern, and there are known url parsing libraries already.
If you are interested in parsing that kinda thing you should totally make an npm module that does it - then anyone who wants to parse that kind of connection string can do like:
Hey! Thanks for the thoughtful response to clarify, much appreciated. I'll close this issue for now, give this idea some more thought with these notes in mind on my own time, see if anything shakes out. I'll ping back here if I do ever get around to publishing anything
and writing text parsers is always a kinda edge case ridden footgun experience.
haha, oh lordy. I was afraid of that. A good learning experience, if painful, i suppose 😆
Hi there,
First off, I apologize if this isn't the right place for semi-random questions. Happy to go elsewhere if I'm off base here, not my intention at all to assume free help.
Anyway, I've been curious:
pg
package'sConnection.getLibpqConnectionString
?So, just as you can input a connection URI e.g.
new Client({ connectionString: 'postgresql://dbuser:secretpassword@localhost:5432/mydb' })
,would there be any value to allowing a user to configure a client with an equivalent key/val string e.g. something like
new Client({ connectionString: "dbname=mydb user=dbuser password=secretpassword host=localhost port=5432" })
?I assume I'm still missing plenty here, but immediately, I can see the connection URI format feels maybe easier to write and, I assume, more familiar from other database engines e.g. mysql. Also, I know the key/val string format has rules for allowing spaces within identifiers and escaping that would further complicate writing in this format.
That said, if supporting this feature / "feature", more in the interest of theoretical completeness, would be even potentially useful, I'd be more than happy to contribute
Thanks for all the massive effort behind this tool; much appreciated!
The text was updated successfully, but these errors were encountered: