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: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: review: CHECK FUNCTION statement
Date: 2011-11-29 17:15:26
Message-ID: 22600.1322586926@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2011/11/29 Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>:
>> 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 call a functions from pg_compile and pg_exec files -
> checking is between compilation and execution - so some functions
> should not be static now. All plpgsql public functions should start
> with plpgsql_ prefix. It is reason for renaming.

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 really need a new
source file. If that results in having to export functions that
otherwise could stay static, maybe it's not the best choice.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-11-29 17:29:56 Re: GiST range-contained-by searches versus empty ranges
Previous Message Jeff Davis 2011-11-29 17:09:21 Re: GiST range-contained-by searches versus empty ranges