Re: review: CHECK FUNCTION statement

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: review: CHECK FUNCTION statement
Дата
Msg-id 22367.1322672326@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: review: CHECK FUNCTION statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: review: CHECK FUNCTION statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Large number of open(2) calls with bulk INSERT into empty table