Re: [HACKERS] [PATCH] pgpassfile connection option

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] [PATCH] pgpassfile connection option
Дата
Msg-id 20355.1485296256@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH] pgpassfile connection option  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> I've switch in the CF to "ready for committer", and we'll see what the 
> next level thinks about it:-)

Pushed with a few adjustments:

* It seemed to me that the appropriate parameter name is "passfile"
not "pgpassfile".  In all but a couple of legacy cases, the environment
variable's name is the parameter name plus a PG prefix; therefore,
with the environment variable already named PGPASSFILE, we have to use
"passfile" for consistency.  Putting a PG prefix on a connection parameter
name is rather pointless anyway, since there's no larger namespace that
it might have a conflict in.

* The error handling in the submitted patch was pretty shoddy; it didn't
check for malloc failure at all, and it didn't report a suitable error on
pqGetHomeDirectory failure either (which is worth doing, if it's going to
be a reason for connection failure).  I ended up concluding that the
easiest way to fix that involved just inlining getPgPassFilename into the
one remaining call site.

* I also got rid of the assignment of DefaultPassword to conn->pgpass;
that wasn't doing anything very useful anymore.  AFAICS, the only visible
effect was to make PQpass() return an empty string not NULL, but we can
make that happen without paying a malloc/free cycle for it.

* Minor comment and docs cleanups.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: [HACKERS] Re: [bug fix] Cascading standby cannot catch up and getstuck emitting the same message repeatedly
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: Add pg_sequence system catalog