Re: Bug in SQL/MED? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bug in SQL/MED?
Date
Msg-id 22122.1309890867@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug in SQL/MED?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Bug in SQL/MED?
List 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 by date:

Previous
From: Brar Piening
Date:
Subject: Re: %ENV warnings during builds
Next
From: "Kevin Grittner"
Date:
Subject: Re: SSI atomic commit