Tony Caduto <[EMAIL PROTECTED]> writes:
> It does not seem to be doing anything differently than 8.0.x does with
> function syntax checking at create time, so why even mention it in the
> release notes?
The checking is more extensive than it was in 8.0. For example 8.0
didn't reject this at creation:
regression=# create function bla() returns int as 'begin zit; end' language
plpgsql;
ERROR: syntax error at or near "zit" at character 1
QUERY: zit
CONTEXT: SQL statement in PL/PgSQL function "bla" near line 1
LINE 1: zit
^
regression=#
because 8.0 didn't feed any apparent SQL statements down to the main
SQL grammar to see if they were sane according to the main grammar.
But it remains purely *syntactic*. If the code gets through the
grammar then it's accepted. What this boils down to is that we
don't apply any checking that depends on anything outside the
function itself (for example, whether something that is used as
a type name actually exists in pg_type).
> How difficult would it be to have the server just run the function at
> create time with null for any input params?
What happens if the function (intentionally) errors out on null inputs?
Or goes into an infinite loop? (If it's declared STRICT then the
programmer would be quite within his rights not to handle such a case.)
What happens if the function changes the database on the basis of the
bogus call? How much would this actually prove, considering that null
inputs would be likely not to exercise many of the code paths within the
function?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
