On Fri, Sep 22, 2023 at 3:24 PM Dominique Devienne <ddevienne@gmail.com> wrote:
> I'm talking of replacing using my tool then psql, with using my tool that forks psql.
I thought you were talking about forking the source code to write your
own psql, sorry about that.
It is clear to me that you mean Unix fork(2) and exec(2).
> The point if about the best way to not expose the password, if a password is necessary.
As I understand the point, which is apparently really hard for me, one
way is using .pgpass (for example adding/removing lines from your
tools, that is effectively a psql wrapper in this sense).
>
> I already told you my app is LIBPQ aware, including about PGPASSWORD and PGSERVICE.
> It's users who decide to use these mechanisms (which have plain-text passwords BTW...), not my tool.
It cannot be your tool, it is the database that asks for a password if
needed (i.e., pg_hba.conf).
Therefore, if your tool is PGPASSWORD aware, it can handle dynamic
lines in .pgpass, which apparently is the simplest and most secure way
to avoid other users spoofing on passwords using ps(1) and friends.
Or pass the environment variable as it is: you are already risking at
the entry point of your tool.
> So in that case, the password must be communicated to PSQL anyways, somehow.
> And the somehow is exactly the point of my questions here.
The options are what you already have mentioned: environment
variables, stdin, and .pgpass.
I'm not aware of any other method, so I thjnk the decision is up to you.
> PSQL is not willy-nilly changing its CLI options or the way it operates.
> Plus I bundled PSQL in my package, which is standalone and cross-platforms.
> And again, I really don't see what's the harm is forking PSQL versus running it directly,
I was referring to source code forking, not fork(2).
> And instead of re-inventing the wheel (in my tool) to capture DDLs, reusing pg_dump
> makes complete sense to me.
>
You added information I was not aware before: you are dumping
PostgreSQL to restore it into SQLite, while I was thinking you wanted
to do some stuff with a PostgreSQL-to-PostgreSQL backup and restore.
That is why I was suggesting to stick with a tool and not to mix and
match.
Apparently you have already what you need, or quite frankly I'm not
getting your actual need.
> That's not the kind of answers (or questions / comments) I was expecting, from this ML.
Sorry about that, hope you will find the correct answer.
Luca
