Re: [HACKERS] update_pg_pwd

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] update_pg_pwd
Дата
Msg-id 11680.945099849@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] update_pg_pwd  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Ответы Re: [HACKERS] update_pg_pwd  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> On Sun, 12 Dec 1999, Tom Lane wrote:
>> opr_sanity is complaining because the declared return type is 0.
>> I am not very happy about taking out opr_sanity's check on return types;
>> perhaps I should lobby to have Opaque-valued trigger functions be
>> declared with an actually valid return-type OID.  What do you think?

> Please don't lose me here. Did I do something wrong?

No, I think you coded the function the way it's currently done.  I'm
just muttering that the way it's currently done needs rethinking.

> If you have to tailor functionality around the regression tests, this is
> not the right direction. After all 0 is a valid oid in this context: it's
> opaque.

The thing I'm unhappy about is that "0" is being overloaded way too far
as a function argument/result type in pg_proc.  Currently it could mean:* unused position in proargtype array;*
erroneousdefinition;* "C string" parameter to a type input function (but, for who  knows what reason, C string outputs
fromtype-output functions  are represented differently);* user proc returning some kind of tuple;* user proc returning
nothingin particular;
 
and who knows what else.  This is bogus.  I've complained before that
there ought to be a specific OID value associated with "C string" and
that type input/output functions ought to be declared to take or return
that type ID, even though it wouldn't be a "real" type in the sense of
ever appearing as a column type.  The parser already has a similar
concept in its "UNKNOWN" type, which it uses for string constants that
are of as-yet-undetermined type.  UNKNOWN is real to the extent of
having a specific OID.

I'm thinking maybe we ought to invent another type OID (or two?) that
can be used for user functions that are declared OPAQUE.  Triggers in
particular.  That would allow more error checking, and it'd let me take
out the kluges that presently exist in the opr_sanity regress test to
keep it from spitting up on things that are practically
indistinguishable from genuine errors.
        regards, tom lane


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

Предыдущее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] Datatype MONEY
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] update_pg_pwd