Re: [HACKERS] NULL as an argument in plpgsql functions
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] NULL as an argument in plpgsql functions |
Дата | |
Msg-id | 20744.938968366@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] NULL as an argument in plpgsql functions (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
Thomas Lockhart <lockhart@alumni.caltech.edu> writes: >> probably be better to mark the Const node as having type UNKNOWN instead >> of type 0 (but make_const is not the only place that makes null >> constants this way! we'd need to find all the others...). But I am not >> sure whether ParseFuncOrColumn would then do the right thing in terms of >> resolving the type of the function; for that matter I'm not real sure >> what the right thing for it to do is. >> Thomas, this stuff is mostly your bailiwick; what do you think? > My recollection is that UNKNOWN usually applies to strings of > unspecified type, while "0" applies to NULL fields. I can put this on > my list to look at later. OK, but after mulling it over it seems that UNKNOWN is pretty much what we want for an explicit null constant. If you want to consider NULL as having a type different from UNKNOWN, then most of the places that currently check for UNKNOWN would have to check for both, no? > Another side issue; any function called with a null parameter will > actually not get called at all! Postgres assumes that a function > called with null must return null, so doesn't bother calling the > routine... Actually, it's even sillier than that: the function *is* called, but then the OR of the input values' nullflags is attached to the output, so you get back a null no matter what the function did. (This is why all the functions that take pass-by-ref args have to be careful about getting null pointers.) In any case, I hope to see that fixed before 6.6/7.0/whatever our next release is. So we do need a fix for the parser issue. regards, tom lane
В списке pgsql-hackers по дате отправления: