Re: review: CHECK FUNCTION statement - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: review: CHECK FUNCTION statement
Date
Msg-id CAFj8pRD3kmd4hV-TG8axmgp6DbGmFABd4gjwD1twdADiP3=9Fg@mail.gmail.com
Whole thread Raw
In response to Re: review: CHECK FUNCTION statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: review: CHECK FUNCTION statement  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
2012/3/3 Pavel Stehule <pavel.stehule@gmail.com>:
> Hello
>
>>
>> It wasn't all that difficult -- see below.  While at this, I have a
>> question: how attached you are to the current return format for CHECK
>> FUNCTION?
>
> TupleDescr is created by language creator. This ensure exactly
> expected format, because there are no possible registry check function
> with other output tuple descriptor.
>
>>
>> check function f1();
>>                       CHECK FUNCTION
>> -------------------------------------------------------------
>>  In function: 'f1()'
>>  error:42804:5:assignment:subscripted object is not an array
>> (2 rows)
>>
>> It seems to me that it'd be trivial to make it look like this instead:
>>
>> check function f1();
>> function | lineno | statement  | sqlstate |              message               | detail | hint | level | position |
query
>>
---------+--------+------------+----------+------------------------------------+--------+------+-------+----------+-------
>> f1()     |      5 | assignment | 42804    | subscripted object is not an array |        |      | error |          |
>> (1 row)
>>
>> This looks much nicer to me.

This was similar to first design - it is near to result of direct PL
check function call. But Tom and Albe had different opinion - check a
thread three months ago, and I had to agree with them - they proposed
better behave for using in psql console - and result is more similar
to usual output when exception is raised.

>
> I am strongly disagree.
>
> 1. This format is not consistent with other commands,
> 2. This format is difficult for copy/paste
> 3. THE ARE NOT CARET - this is really important
> 5. This form is bad for terminals - there are long rows, and with \x
> outout, there are lot of "garbage" for multicommand
> 4. When you would to this form, you can to directly call SRF PL check
> functions.
>
>>
>> One thing we lose is the caret marking the position of the error -- but
>> I'm wondering if that really works well.  I didn't test it but from the
>> code it looks to me like it'd misbehave if you had a multiline statement.
>>
>> Opinions?
>
>
>
>>
>>
>> /*
>>  * Search and execute the checker function.
>>  *
>>  *   returns true, when checked function is valid
>>  */
>> static bool
>> CheckFunctionById(Oid funcOid, Oid relid, ArrayType *options,
>>                                  bool fatal_errors, TupOutputState *tstate)
>> {
>>        HeapTuple               tup;
>>        Form_pg_proc    proc;
>>        HeapTuple               languageTuple;
>>        Form_pg_language lanForm;
>>        Oid                             languageChecker;
>>        char               *funcname;
>>        int                             result;
>>
>>        tup = SearchSysCache1(PROCOID, ObjectIdGetDatum(funcOid));
>>        if (!HeapTupleIsValid(tup)) /* should not happen */
>>                elog(ERROR, "cache lookup failed for function %u", funcOid);
>>
>>        proc = (Form_pg_proc) GETSTRUCT(tup);
>>
>>        languageTuple = SearchSysCache1(LANGOID, ObjectIdGetDatum(proc->prolang));
>>        Assert(HeapTupleIsValid(languageTuple));
>>
>>        lanForm = (Form_pg_language) GETSTRUCT(languageTuple);
>>        languageChecker = lanForm->lanchecker;
>>
>>        funcname = format_procedure(funcOid);
>>
>>        /* We're all set to call the checker */
>>        if (OidIsValid(languageChecker))
>>        {
>>                TupleDesc               tupdesc;
>>                Datum                   checkret;
>>                FmgrInfo                flinfo;
>>                ReturnSetInfo   rsinfo;
>>                FunctionCallInfoData fcinfo;
>>
>>                /* create the tuple descriptor that the checker is supposed to return */
>>                tupdesc = CreateTemplateTupleDesc(10, false);
>>                TupleDescInitEntry(tupdesc, (AttrNumber) 1, "functionid", REGPROCOID, -1, 0);
>>                TupleDescInitEntry(tupdesc, (AttrNumber) 2, "lineno", INT4OID, -1, 0);
>>                TupleDescInitEntry(tupdesc, (AttrNumber) 3, "statement", TEXTOID, -1, 0);
>>                TupleDescInitEntry(tupdesc, (AttrNumber) 4, "sqlstate", TEXTOID, -1, 0);
>>                TupleDescInitEntry(tupdesc, (AttrNumber) 5, "message", TEXTOID, -1, 0);
>>                TupleDescInitEntry(tupdesc, (AttrNumber) 6, "detail", TEXTOID, -1, 0);
>>                TupleDescInitEntry(tupdesc, (AttrNumber) 7, "hint", TEXTOID, -1, 0);
>>                TupleDescInitEntry(tupdesc, (AttrNumber) 8, "level", TEXTOID, -1, 0);
>>                TupleDescInitEntry(tupdesc, (AttrNumber) 9, "position", INT4OID, -1, 0);
>>                TupleDescInitEntry(tupdesc, (AttrNumber) 10, "query", TEXTOID, -1, 0);
>>
>>                fmgr_info(languageChecker, &flinfo);
>>
>>                rsinfo.type = T_ReturnSetInfo;
>>                rsinfo.econtext = CreateStandaloneExprContext();
>>                rsinfo.expectedDesc = tupdesc;
>>                rsinfo.allowedModes = (int) SFRM_Materialize;
>>                /* returnMode is set by the checker, hopefully ... */
>>                /* isDone is not relevant, since not using ValuePerCall */
>>                rsinfo.setResult = NULL;
>>                rsinfo.setDesc = NULL;
>>
>>                InitFunctionCallInfoData(fcinfo, &flinfo, 4, InvalidOid, NULL, (Node *) &rsinfo);
>>                fcinfo.arg[0] = ObjectIdGetDatum(funcOid);
>>                fcinfo.arg[1] = ObjectIdGetDatum(relid);
>>                fcinfo.arg[2] = PointerGetDatum(options);
>>                fcinfo.arg[3] = BoolGetDatum(fatal_errors);
>>                fcinfo.argnull[0] = false;
>>                fcinfo.argnull[1] = false;
>>                fcinfo.argnull[2] = false;
>>                fcinfo.argnull[3] = false;
>>
>>                checkret = FunctionCallInvoke(&fcinfo);
>>
>>                if (rsinfo.returnMode != SFRM_Materialize)
>>                        elog(ERROR, "checker function didn't return a proper return set");
>>                /* XXX we have to do some checking on rsinfo.isDone and checkret here */
>>
>>                if (rsinfo.setResult != NULL)
>>                {
>>                        bool    isnull;
>>                        StringInfoData  str;
>>                        TupleTableSlot  *slot = MakeSingleTupleTableSlot(tupdesc);
>>
>>                        initStringInfo(&str);
>>
>>                        while (tuplestore_gettupleslot(rsinfo.setResult, true, false, slot))
>>                        {
>>                                text *message = (text *) DatumGetPointer(slot_getattr(slot, 5, &isnull));
>>
>>                                resetStringInfo(&str);
>>
>>                                appendStringInfo(&str, "got a message: %s", text_to_cstring(message));
>>                                do_text_output_oneline(tstate, str.data);
>>                        }
>>
>>                        pfree(str.data);
>>                        ExecDropSingleTupleTableSlot(slot);
>>                }
>>        }
>>
>>        pfree(funcname);
>>
>>        ReleaseSysCache(languageTuple);
>>        ReleaseSysCache(tup);
>>
>>        return result;
>> }
>>
>
> Without correct registration you cannot to call PL check function
> directly simply. I don't thing so this is good price for removing a
> few SPI lines. I don't understand why you don't like SPI. It is used
> more times in code for similar purpose.
>
> so from me -1

this disallow direct PL check function call - so any more complex
situation cannot be solved by SQL, but must be solved by PL/pgSQL with
dynamic SQL

so I don't like it. We can talk about format for check_options - but I
don't would to lost a possibility to simple call check function.

Regards

Pavel

>
> Regards
>
> Pavel Stehule
>
>>
>> --
>> Álvaro Herrera <alvherre@commandprompt.com>
>> The PostgreSQL Company - Command Prompt, Inc.
>> PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: review: CHECK FUNCTION statement
Next
From: Alvaro Herrera
Date:
Subject: Re: review: CHECK FUNCTION statement