Re: Bug in SQL/MED?
От | Tom Lane |
---|---|
Тема | Re: Bug in SQL/MED? |
Дата | |
Msg-id | 22122.1309890867@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Bug in SQL/MED? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Bug in SQL/MED?
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > 2011/7/1 Shigeru Hanada <shigeru.hanada@gmail.com>: >> I used ereport for the former check, because maybe such error usually >> happens and is visible to users. This criteria was taken from the >> document "Reporting Errors Within the Server". >> http://developer.postgresql.org/pgdocs/postgres/error-message-reporting.html > Do we want to apply this to 9.1 before beta3? The original patch in this thread seems pretty bogus to me, because it changes only one place of many in foreigncmds.c where PointerGetDatum(NULL) is used as the representation of an empty options list. If we're going to go over to the rule that pg_foreign_data_wrapper.fdwoptions can't be NULL, which is what this is effectively proposing, we need much more extensive changes than this. Also, since foreigncmds.c is sharing code with reloptions.c, wherein the PointerGetDatum(NULL) convention is also used, I'm concerned that we're going to have more bugs added than removed by changing the rule for just pg_foreign_data_wrapper.fdwoptions. I think it might be better to keep the convention that an empty options list is represented by null, and to say that if a validator wants to be called on such a list, it had better declare itself non-strict. At least we ought to think about that before redefining the catalog semantics at this late hour. regards, tom lane
В списке pgsql-hackers по дате отправления: