Skip site navigation (1) Skip section navigation (2)

Re: review: CHECK FUNCTION statement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: review: CHECK FUNCTION statement
Date: 2011-11-30 18:30:03
Message-ID: 24793.1322677803@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> I rechecked a possibility to use a validator function together with
> checker function.

> The main issue is a different interface of both functions. Validator
> needs just function oid and uses global variable
> check_function_bodies. Checker function needs function oid and
> relation oid (possible some other params). When we mix these two
> functions together we need a

> validator(oid) or validator(oid, oid, variadic "any")

Right, although if you want it to be callable from SQL I think that
variadic "any" is too loose.

> What is a correct signature for this function? We cannot use a
> overloading, because we can have only one validator function per
> language.

So?  You have one validator function, it has either signature;
if it has the old signature then CHECK isn't supported by the language.
We have plenty of examples of this sort of thing already.

One issue that would need to be considered is how the validator tells
the difference between a CREATE FUNCTION call and a CHECK call with
default parameters (no WITH clause).  Those shouldn't do exactly the
same thing, presumably.  Maybe that's a sufficient reason to have two
entry points.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-11-30 18:30:58
Subject: Re: Large number of open(2) calls with bulk INSERT into empty table
Previous:From: Robert HaasDate: 2011-11-30 18:26:58
Subject: Re: Why so few built-in range types?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group