Re: pgsql_fdw in contrib
От | Kohei KaiGai |
---|---|
Тема | Re: pgsql_fdw in contrib |
Дата | |
Msg-id | CADyhKSW-2GR1Rv+PZ+Jh5Pzpac6fa_-Y=tkkEBziMEm6EnAUhg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql_fdw in contrib (Shigeru HANADA <shigeru.hanada@gmail.com>) |
Ответы |
Re: pgsql_fdw in contrib
|
Список | pgsql-hackers |
Hanada-san, What about the status of your patch? Even though the 1st commit-fest is getting closed soon, I'd like to pay efforts for reviewing to pull up the status of pgsql_fdw into "ready for committer" by beginning of the upcoming commit-fest. Thanks, 2012/7/13 Shigeru HANADA <shigeru.hanada@gmail.com>: > (2012/07/12 20:48), Kohei KaiGai wrote: >> It seems to me what postgresql_fdw_validator() is doing looks like >> a function to be named as "libpq_fdw_validator()". >> >> How about your opinion? It will help this namespace conflicts. > > I'd prefer dblink_fdw_validator. > > The name "libpq_fdw_validator" impresses me that a concrete FDW named > "libpq_fdw" is somewhere and it retrieves external data *from* libpq. > Indeed postgresql_fdw_validator allows only some of libpq options at the > moment, but we won't be able to rename it for backward compatibility > even if it wants to have non-libpq options in the future. > > IMO basically each FDW validator should be owned by a particular FDW, > because in most cases validator should know FDW's internal deeply. In > addition, it would want to have new options for new features. > > Besides naming, as mentioned upthread, removing hard-coded libpq options > list from dblink and leaving it to libpq client library would make > dblink more robust about libpq option changes in future. > > Regards, > -- > Shigeru HANADA > > -- KaiGai Kohei <kaigai@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления: