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

From Tom Lane
Subject Re: review: CHECK FUNCTION statement
Date
Msg-id 22367.1322672326@sss.pgh.pa.us
Whole thread Raw
In response to Re: review: CHECK FUNCTION statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: review: CHECK FUNCTION statement
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2011/11/30 Tom Lane <tgl@sss.pgh.pa.us>:
>> It seems pretty awkward to me, particularly putting the options before
>> the second keyword of the command --- that could bite us if we ever want
>> some other flavors of CHECK command.  I prefer Robert's suggestion of a
>> WITH clause at the end.

> we can provide both versions - as can be fine for people. Is is simple
> in parser. I like both variants and I am thinking so much more
> important is a API of checker function and behave of CHECK FUNCTION
> statement.

I think you missed my point: I don't want the options list at the front
because I'm afraid it will prevent us from making good extensions in the
future.  Offering both syntaxes does not fix that.

> Just idea - don't kill me :). Because CHECK FUNCTION  is not
> destructive , then complete signature is not necessary, and when
> function name is unique, then parameters should be optional - it can
> be comfortable for manual work, so just CHECK FUNCTION name; can work.

Well, there was some discussion of having a "bulk check" or wildcard
capability in the CHECK command, but this seems like an awfully
constricted version of that.

The thing I'd prefer to see in the first cut is some notation for "check
all functions owned by me that are in language FOO".  The reason for the
language restriction is that if we think the options are
language-specific, there's no reason to believe that different
validators would accept the same options.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility
Next
From: Robert Haas
Date:
Subject: Re: Large number of open(2) calls with bulk INSERT into empty table