Hello
multicheck for triggers are supported now
CHECK TRIGGER ALL;
CHECK TRIGGER ALL IN SCHEMA xxx FOR ROLE yyy;
Regards
Pavel Stehule
check_function-2012-03-07-2.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
Hello
I found one small issue where Query was not forwarded when trigger
record was broken. I had to append "context" forwarding.
Regards
Pavel
2012/3/6 Pavel Stehule :
> Hello
>
> there is new version
>
> * fixed small formatting issues related to drop SPI call
> * long functions was divided
>
Hello
there is new version
* fixed small formatting issues related to drop SPI call
* long functions was divided
* CREATE TRIGGER ALL ON table support
Regards
Pavel
check_function-2012-03-06-3.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hacker
2012/3/6 Alvaro Herrera :
>
> Excerpts from Pavel Stehule's message of mar mar 06 10:44:09 -0300 2012:
>>
>> 2012/3/6 Alvaro Herrera :
>> >
>> > Excerpts from Pavel Stehule's message of mar mar 06 03:43:06 -0300 2012:
>> >> Hello
>> >>
>> >> * I refreshed regress tests and appended tests for multi
Excerpts from Pavel Stehule's message of mar mar 06 03:43:06 -0300 2012:
> Hello
>
> * I refreshed regress tests and appended tests for multi lines query
> * There are enhanced checking of SELECT INTO statement
> * I fixed showing details and hints
Oh, I forgot to remove the do_tup_output_slot()
Hello
* I refreshed regress tests and appended tests for multi lines query
* There are enhanced checking of SELECT INTO statement
* I fixed showing details and hints
Regards
Pavel Stehule
2012/3/5 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of lun mar 05 13:02:50 -0300 2012:
>> sm
Excerpts from Pavel Stehule's message of lun mar 05 13:02:50 -0300 2012:
> small fix of CheckFunctionById function
>
> Regards
>
> p.s. Alvaro, please, send your patch and I'll merge it
Here it is, with your changes already merged. I also added back the
new reference doc files which were droppe
small fix of CheckFunctionById function
Regards
p.s. Alvaro, please, send your patch and I'll merge it
/*
* Connect to SPI manager
*/
if (SPI_connect() != SPI_OK_CONNECT)
elog(ERROR, "SPI_connect failed");
values[0] = ObjectIdGetDatum(funcOid);
values[1] = ObjectIdGetDatum(relid
Hello
2012/3/5 Alvaro Herrera :
>
> Excerpts from Pavel Stehule's message of dom mar 04 16:33:08 -0300 2012:
>>
>> Hello
>>
>> 2012/3/4 Alvaro Herrera :
>
>> > CHECK FUNCTION
>> > -
>> > In function: 'f()'
>> > error:42P
Excerpts from Pavel Stehule's message of dom mar 04 16:33:08 -0300 2012:
>
> Hello
>
> 2012/3/4 Alvaro Herrera :
> > CHECK FUNCTION
> > -
> > In function: 'f()'
> > error:42P01:2:sentencia SQL:no existe la relación «f
Hello
2012/3/4 Alvaro Herrera :
>
> Excerpts from Alvaro Herrera's message of sáb mar 03 17:56:23 -0300 2012:
>> Excerpts from Alvaro Herrera's message of sáb mar 03 16:54:19 -0300 2012:
>> > Excerpts from Pavel Stehule's message of sáb mar 03 02:25:52 -0300 2012:
>>
>> > > 3. THE ARE NOT CARET -
Excerpts from Alvaro Herrera's message of sáb mar 03 17:56:23 -0300 2012:
> Excerpts from Alvaro Herrera's message of sáb mar 03 16:54:19 -0300 2012:
> > Excerpts from Pavel Stehule's message of sáb mar 03 02:25:52 -0300 2012:
>
> > > 3. THE ARE NOT CARET - this is really important
>
> > I am no
Excerpts from Alvaro Herrera's message of sáb mar 03 16:54:19 -0300 2012:
> Excerpts from Pavel Stehule's message of sáb mar 03 02:25:52 -0300 2012:
> > 3. THE ARE NOT CARET - this is really important
> I am not sure about the caret thingy -- mainly because I don't think it
> works all that well
Excerpts from Pavel Stehule's message of sáb mar 03 02:25:52 -0300 2012:
> 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. Th
Excerpts from Petr Jelínek's message of sáb mar 03 10:26:04 -0300 2012:
> On 03/03/2012 02:24 AM, Alvaro Herrera wrote:
> > question: how attached you are to the current return format for CHECK
> > FUNCTION?
> >
> > check function f1();
> > CHECK FUNCTION
> > --
On 03/03/2012 02:24 AM, Alvaro Herrera wrote:
question: how attached you are to the current return format for CHECK
FUNCTION?
check function f1();
CHECK FUNCTION
-
In function: 'f1()'
error:42804:5:assignment
2012/3/3 Alvaro Herrera :
>
> Excerpts from Pavel Stehule's message of sáb mar 03 02:45:06 -0300 2012:
>
>> > 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
Excerpts from Pavel Stehule's message of sáb mar 03 02:45:06 -0300 2012:
> > 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.
I don't dislike SPI
2012/3/3 Pavel Stehule :
> 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
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
w
Excerpts from Pavel Stehule's message of mar feb 28 16:30:58 -0300 2012:
> Hello
>
> Dne 28. února 2012 17:48 Alvaro Herrera
> napsal(a):
> >
> >
> > I have a few comments about this patch:
> >
> > I didn't like the fact that the checker calling infrastructure uses
> > SPI instead of just a Fun
Hello
2012/3/2 Alvaro Herrera :
>
> Excerpts from Pavel Stehule's message of vie mar 02 05:29:26 -0300 2012:
>
>> you cannot to check trigger function without assigned relation -
>> TupleDescription should be assigned to NEW and OLD variables.
>
> Oh, I see, that makes sense.
>
> After mulling ove
Excerpts from Pavel Stehule's message of vie mar 02 05:29:26 -0300 2012:
> you cannot to check trigger function without assigned relation -
> TupleDescription should be assigned to NEW and OLD variables.
Oh, I see, that makes sense.
After mulling over this a bit, I'm dubious about having two se
2012/3/2 Alvaro Herrera :
> I've cleaned up the backend code a bit -- see attached. More yet to go
> through; I'm mainly sending it out for you (and everyone, really) to
> give your opinion on my changes so far.
>
> (I split out the plpgsql checker for the time being into a separate
> branch; I'll
Hello
2012/3/1 Alvaro Herrera :
>
>
> Why does CollectCheckedFunctions skip trigger functions? My only guess
> is that at one point the checker was not supposed to know how to check
> them, and a later version learned about it and this bit wasn't updated;
> but maybe there's another reason?
you
Why does CollectCheckedFunctions skip trigger functions? My only guess
is that at one point the checker was not supposed to know how to check
them, and a later version learned about it and this bit wasn't updated;
but maybe there's another reason?
--
Álvaro Herrera
The PostgreSQL Company - Co
Hello
2012/2/29 Alvaro Herrera :
>
> I think the way we're passing down the options to the checker is a bit
> of a mess. The way it is formulated, it seems to me that we'd need to
> add support code in the core CheckFunction for each option we might want
> to accept in the PL-specific checkers --
I think the way we're passing down the options to the checker is a bit
of a mess. The way it is formulated, it seems to me that we'd need to
add support code in the core CheckFunction for each option we might want
to accept in the PL-specific checkers -- including what type of value
the option re
Hello
2012/2/28 Alvaro Herrera :
>
>
> In gram.y we have a new check_option_list nonterminal. This is mostly
> identical to explain_option_list, except that the option args do not
> take a NumericOnly (only opt_boolean_or_string and empty). I wonder if
> it's really worthwhile having a bunch of
2012/2/28 Alvaro Herrera :
>
>
> In gram.y we have a new check_option_list nonterminal. This is mostly
> identical to explain_option_list, except that the option args do not
> take a NumericOnly (only opt_boolean_or_string and empty). I wonder if
> it's really worthwhile having a bunch of separat
In gram.y we have a new check_option_list nonterminal. This is mostly
identical to explain_option_list, except that the option args do not
take a NumericOnly (only opt_boolean_or_string and empty). I wonder if
it's really worthwhile having a bunch of separate productions for this;
how about we
2012/2/28 Alvaro Herrera :
>
> Excerpts from Pavel Stehule's message of mar feb 28 16:30:58 -0300 2012:
>
>> I refreshed patch for current git repository.
>
> Thanks, I'll have a look.
>
> Oh, another thing -- you shouldn't patch the 1.0 version of the plpgsql
> extension. Rather I think you shoul
Excerpts from Pavel Stehule's message of mar feb 28 16:30:58 -0300 2012:
> I refreshed patch for current git repository.
Thanks, I'll have a look.
Oh, another thing -- you shouldn't patch the 1.0 version of the plpgsql
extension. Rather I think you should produce a 1.1 version.
--
Álvaro Her
Hello
Dne 28. února 2012 17:48 Alvaro Herrera napsal(a):
>
>
> I have a few comments about this patch:
>
> I didn't like the fact that the checker calling infrastructure uses
> SPI instead of just a FunctionCallN to call the checker function. I
> think this should be easily avoidable.
>
It is n
I have a few comments about this patch:
I didn't like the fact that the checker calling infrastructure uses
SPI instead of just a FunctionCallN to call the checker function. I
think this should be easily avoidable.
Second, I see that functioncmds.c gets a lot into trigger internals just
to be
Pavel Stehule wrote:
> here is new version of CHECK FUNCTION patch
>
> I changed implementation of interface:
>
> * checked functions returns table instead raising exceptions - it
> necessary for describing more issues inside one function - and it
> allow to use better structured data then Except
Pavel Stehule wrote:
> here is new version of CHECK FUNCTION patch
I won't be able to review that one because I'll be in
California from Jan 6 to Jan 29.
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
Hello all
here is new version of CHECK FUNCTION patch
I changed implementation of interface:
* checked functions returns table instead raising exceptions - it
necessary for describing more issues inside one function - and it
allow to use better structured data then ExceptionData
postgres=# sel
2011/12/19 Greg Smith :
> On 12/17/2011 04:00 PM, Pavel Stehule wrote:
>>
>> I use it for checking of my most large plpgsql project - it is about
>> 300KB plpgsql procedures - but this code is not free - and this module
>> helps to find lot of bugs.
>
>
> Great. If you continue to check against th
On 12/17/2011 04:00 PM, Pavel Stehule wrote:
I use it for checking of my most large plpgsql project - it is about
300KB plpgsql procedures - but this code is not free - and this module
helps to find lot of bugs.
Great. If you continue to check against that regularly, that makes me
feel better
Hello
>
> You have the option "fatal_errors" for the checker function, but you
> special case it in CheckFunction(CheckFunctionStmt *stmt) and turn
> errors to warnings if it is not set.
>
> Wouldn't it be better to have the checker function ereport a WARNING
> or an ERROR depending on the setting
2011/12/16 Greg Smith :
> I just poked at this a bit myself to see how the patch looked. There's just
> over 4000 lines in the diff. Even though 1/4 of that is tests, which is
> itself encouraging, that's still a good sized feature. The rate at which
> code here has still been changing regularly
2011/12/16 Albe Laurenz :
> Pavel Stehule wrote:
>> one small update - better emulation of environment for security
>> definer functions
>
> Patch applies and compiles fine, core functionality works fine.
>
> I found a little bug:
>
> In backend/commands/functioncmds.c,
> function CheckFunction(Che
I just poked at this a bit myself to see how the patch looked. There's
just over 4000 lines in the diff. Even though 1/4 of that is tests,
which is itself encouraging, that's still a good sized feature. The
rate at which code here has still been changing regularly here has me
nervous about c
Pavel Stehule wrote:
> one small update - better emulation of environment for security
> definer functions
Patch applies and compiles fine, core functionality works fine.
I found a little bug:
In backend/commands/functioncmds.c,
function CheckFunction(CheckFunctionStmt *stmt),
while you perform
Hello
one small update - better emulation of environment for security
definer functions
Regards
Pavel
check_function-2011-12-15-2.diff.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
Hello
2011/12/15 Albe Laurenz :
> Pavel Stehule wrote:
>> so removed "quite" option
>> and removed multiple check regression tests also - there is missing
>> explicit order of function checking, so regress tests can fail :(
>
> There seems to be a problem with the SET clause of CREATE FUNCTION:
>
Pavel Stehule wrote:
> so removed "quite" option
> and removed multiple check regression tests also - there is missing
> explicit order of function checking, so regress tests can fail :(
There seems to be a problem with the SET clause of CREATE FUNCTION:
ftest=# CREATE OR REPLACE FUNCTION a(integ
Hello
so removed "quite" option
and removed multiple check regression tests also - there is missing
explicit order of function checking, so regress tests can fail :(
Regards
Pavel
2011/12/14 Albe Laurenz :
> Pavel Stehule wrote:
>> changes:
>>
>> * fixed warnings
>> * support for options - act
Pavel Stehule wrote:
> changes:
>
> * fixed warnings
> * support for options - actually only two options are supported -
> quite and fatal_errors
>
> these options are +/- useful - main reason for their existence is
> testing of support of options - processing on CHECK ... stmt side and
> proces
Hello
2011/12/12 Albe Laurenz :
> Pavel Stehule wrote:
>> there is merged patch
>
> Works fine, except that there are still missing const qualifiers
> in copyfuncs.c and equalfuncs.c that lead to compiler warnings.
>
> One thing I forgot to mention:
> I thought there was a consensus to add a WITH(
2011/12/13 Tom Lane :
> Pavel Stehule writes:
>> 2011/12/13 Albe Laurenz :
>>> Either that, or couldn't you pass an option List as data type "internal"?
>
>> this is question - internal is most simply solution, but then we
>> cannot to call check function directly
>
> Yeah, one of the proposals fo
Pavel Stehule writes:
> 2011/12/13 Albe Laurenz :
>> Either that, or couldn't you pass an option List as data type "internal"?
> this is question - internal is most simply solution, but then we
> cannot to call check function directly
Yeah, one of the proposals for allowing people to specify com
2011/12/13 Albe Laurenz :
> Pavel Stehule wrote:
>>> One thing I forgot to mention:
>>> I thought there was a consensus to add a WITH() or OPTIONS() clause
>>> to pass options to the checker function:
>>> http://archives.postgresql.org/message-id/12568.1322669...@sss.pgh.pa.us
>>>
>>> I think this
Pavel Stehule wrote:
>> One thing I forgot to mention:
>> I thought there was a consensus to add a WITH() or OPTIONS() clause
>> to pass options to the checker function:
>> http://archives.postgresql.org/message-id/12568.1322669...@sss.pgh.pa.us
>>
>> I think this should be there so that the API do
hello
2011/12/12 Albe Laurenz :
> Pavel Stehule wrote:
>> there is merged patch
>
> Works fine, except that there are still missing const qualifiers
> in copyfuncs.c and equalfuncs.c that lead to compiler warnings.
>
> One thing I forgot to mention:
> I thought there was a consensus to add a WITH(
Pavel Stehule wrote:
> there is merged patch
Works fine, except that there are still missing const qualifiers
in copyfuncs.c and equalfuncs.c that lead to compiler warnings.
One thing I forgot to mention:
I thought there was a consensus to add a WITH() or OPTIONS() clause
to pass options to the c
Hello
2011/12/9 Albe Laurenz :
> Pavel Stehule wrote:
>> there is fixed version
>
> Here is my attempt at a doc patch.
>
> Could you add it to your patch so that all is in a single patch?
>
there is merged patch
Thank you
Regards
Pavel
> Yours,
> Laurenz Albe
check_function-2011-12-09-3.dif
Pavel Stehule wrote:
> there is fixed version
Here is my attempt at a doc patch.
Could you add it to your patch so that all is in a single patch?
Yours,
Laurenz Albe
check_function_docs.patch
Description: check_function_docs.patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
Pavel Stehule wrote:
> updated version
>
> changes:
>
> * CHECK FUNCTION ALL; is enabled - in this case functions from
> pg_catalog schema are ignored
>
> I looked on parser, and I didn't other changes there - IN SCHEMA, FOR
> ROLE are used more time there, so our usage will be consistent
> a smal
Pavel Stehule wrote:
>> The syntax error messages are still inadequate; all I can get is
>> 'syntax error at or near "%s"'. They should be more detailed.
>
> this system is based on error messages that generates a plpgsql engine
> or bison engine. I can correct only a few percent from these messa
2011/12/7 Albe Laurenz :
> Pavel Stehule wrote:
>> there is a updated patch.
>>
>> it support multi check, options and custom check functions are not
>> supported yet. I don't plan to implement custom check functions in
>> this round - I has not any example of usage - but we have agreement on
>> sy
Pavel Stehule wrote:
> there is a updated patch.
>
> it support multi check, options and custom check functions are not
> supported yet. I don't plan to implement custom check functions in
> this round - I has not any example of usage - but we have agreement on
> syntax and behave, so this should
Pavel Stehule wrote:
>> My attempt at a syntax that could also cover Peter's wish for multiple
>> checker functions:
>>
>> CHECK FUNCTION { func(args) | ALL [IN SCHEMA schema] [FOR ROLE user] }
>> [ USING check_function ] OPTIONS (optname optarg [, ...])
> check_function should be related to one
2011/12/2 Pavel Stehule :
> Hello
>
>>
>> My attempt at a syntax that could also cover Peter's wish for multiple
>> checker functions:
>>
>> CHECK FUNCTION { func(args) | ALL [IN SCHEMA schema] [FOR ROLE user] }
>> [ USING check_function ] OPTIONS (optname optarg [, ...])
>>
>
some other idea abo
Hello
>
> My attempt at a syntax that could also cover Peter's wish for multiple
> checker functions:
>
> CHECK FUNCTION { func(args) | ALL [IN SCHEMA schema] [FOR ROLE user] }
> [ USING check_function ] OPTIONS (optname optarg [, ...])
>
check_function should be related to one language, so you
Hello
>
>> Also, what kind of report does this generate?
>
> Good question. I suspect what Pavel has now will raise errors, but that
> doesn't scale very nicely to checking more than one function, or even to
> finding more than one bug in a single function.
>
I stop on first error now. Reason is
Peter Eisentraut writes:
> On ons, 2011-11-30 at 10:53 -0500, Tom Lane wrote:
>> I think the important point here is that we need to support more than
>> one level of validation, and that the higher levels can't really be
>> applied by default in CREATE FUNCTION because they may fail on perfectly
Tom Lane wrote:
>> Do I understand right that the reason why the check function is
>> different from the validator function is that it would be more
difficult
>> to add the checks to the validator function?
>
>> Is that a good enough argument? From a user's perspective it is
>> difficult to see wh
On ons, 2011-11-30 at 10:53 -0500, Tom Lane wrote:
> I think the important point here is that we need to support more than
> one level of validation, and that the higher levels can't really be
> applied by default in CREATE FUNCTION because they may fail on perfectly
> valid code.
How would this w
Pavel Stehule 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 an
Hello
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 s
Pavel Stehule writes:
> 2011/11/30 Tom Lane :
>> 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.
2011/11/30 Tom Lane :
> Pavel Stehule writes:
>> 2011/11/30 Alvaro Herrera :
>>> How about
>>> CHECK (parse, names=off) FUNCTION foobar(a, b, c)
>
>> this syntax is relative consistent with EXPLAIN, is it ok for all?
>
> It seems pretty awkward to me, particularly putting the options before
> the
Pavel Stehule writes:
> 2011/11/30 Alvaro Herrera :
>> How about
>> CHECK (parse, names=off) FUNCTION foobar(a, b, c)
> this syntax is relative consistent with EXPLAIN, is it ok for all?
It seems pretty awkward to me, particularly putting the options before
the second keyword of the command ---
2011/11/30 Alvaro Herrera :
>
> Excerpts from Tom Lane's message of mié nov 30 12:53:42 -0300 2011:
>
>> A bigger issue is that once you think about more than one kind of check,
>> it becomes apparent that we might need some user-specifiable options to
>> control which checks are applied. And I se
Robert Haas writes:
> On Wed, Nov 30, 2011 at 10:53 AM, Tom Lane wrote:
>> On the whole, it might not be a bad idea to have two allowed signatures
>> for the validator function, rather than inventing an additional column
>> in pg_language. But the fundamental point IMHO is that there needs to
>>
Excerpts from Tom Lane's message of mié nov 30 12:53:42 -0300 2011:
> A bigger issue is that once you think about more than one kind of check,
> it becomes apparent that we might need some user-specifiable options to
> control which checks are applied. And I see no provision for that here.
> Thi
On Wed, Nov 30, 2011 at 10:53 AM, Tom Lane wrote:
> On the whole, it might not be a bad idea to have two allowed signatures
> for the validator function, rather than inventing an additional column
> in pg_language. But the fundamental point IMHO is that there needs to
> be a provision to pass lan
Hello
>
> CREATE OR REPLACE FUNCTION t(i integer) RETURNS integer
> LANGUAGE plpgsql STRICT AS
> $$DECLARE j integer;
> BEGIN
> IF i=1 THEN
> FOR I IN 1..4 BY -1 LOOP
> RAISE NOTICE '%', i;
> END LOOP;
> RETURN -1;
> ELSE
> RETURN 2*i;
> EN
"Albe Laurenz" writes:
> Do I understand right that the reason why the check function is
> different from the validator function is that it would be more difficult
> to add the checks to the validator function?
> Is that a good enough argument? From a user's perspective it is
> difficult to see w
Pavel Stehule wrote:
> updated patch:
>
> * recheck compilation and initdb
> * working routines moved to pl_exec.c
> * add entry to catalog.sgml about lanchecker field
> * add node's utils
Documentation:
--
This patch has no documentation for CHECK FUNCTION or CHECK TRIGGER.
The last
2011/11/29 Pavel Stehule :
> Hello
>
> updated patch:
>
> * recheck compilation and initdb
> * working routines moved to pl_exec.c
> * add entry to catalog.sgml about lanchecker field
> * add node's utils
+ pg_dump support
Pavel
>
> Regards
>
> Pavel Stehule
>
> 2011/11/29 Albe Laurenz :
>> Pave
Excerpts from Pavel Stehule's message of mar nov 29 14:37:24 -0300 2011:
> 2011/11/29 Tom Lane :
> > I don't think renaming is necessary. plpgsql is a standalone shared
> > library and so its symbols don't matter to anybody but itself.
> >
> > Possibly a larger question, though, is whether you r
2011/11/29 Tom Lane :
> Pavel Stehule writes:
>> 2011/11/29 Albe Laurenz :
>>> There are a lot of small changes to pl/plpgsql/src/pl_exec.c, are they all
>>> necessary? For example, why was copy_plpgsql_datum renamed to
>>> plpgsql_copy_datum?
>
>> yes, it's necessary - a implementation is in new
Pavel Stehule writes:
> 2011/11/29 Albe Laurenz :
>> There are a lot of small changes to pl/plpgsql/src/pl_exec.c, are they all
>> necessary? For example, why was copy_plpgsql_datum renamed to
>> plpgsql_copy_datum?
> yes, it's necessary - a implementation is in new file and there is
> necessary
Hello
2011/11/29 Albe Laurenz :
> Pavel Stehule wrote:
>> I am sending updated patch, that implements a CHECK FUNCTION and CHECK
>> TRIGGER statements.
>>
>> This patch is significantly redesigned to previous version (PL/pgSQL
>> part) - it is more readable, more accurate. There are new regress
>>
Pavel Stehule wrote:
> I am sending updated patch, that implements a CHECK FUNCTION and CHECK
> TRIGGER statements.
>
> This patch is significantly redesigned to previous version (PL/pgSQL
> part) - it is more readable, more accurate. There are new regress
> tests.
>
> Please, can some English na
2011/11/22 Albe Laurenz :
> I tried to look at the patch, but it does not apply to current master,
> probably because of bit rot.
>
> Can you submit an updated version?
>
> The patch contains docs and regression tests and is context diff.
> I'll mark it "waiting for author".
please wait, I plan to
89 matches
Mail list logo
