Re: schema agnostic functions in language sql - Mailing list pgsql-general

From Rob Sargent
Subject Re: schema agnostic functions in language sql
Date
Msg-id 01AD9083-259E-4F92-85E8-8A254E89716C@gmail.com
Whole thread Raw
In response to Re: schema agnostic functions in language sql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: schema agnostic functions in language sql  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-general

> On May 15, 2020, at 6:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Rob Sargent <robjsargent@gmail.com> writes:
>> I cannot create a plain sql function unless the search_path covers any
>> table mentioned. Not the case when using plpgsql - no path needed.
>
> Oh, one of the things that's quite a lot different is the checking
> applied at function creation time ;-).
>
> For a SQL function, by default we'll try to parse and analyze the body, so
> any unknown tables will draw an error.  plpgsql doesn't go further than a
> very crude syntax check.
>
> If you don't like that, you can set check_function_bodies = off while
> creating your SQL functions.  But in any case, it's only related to what
> happens at execution if the search path is the same.
>
>            regards, tom lane
And my fundamental error was thinking the parse of all create function calls was not language specific beyond syntax.
Lookingback, my use of sql functions has been for inline-able calculations reused in other plpgsql functions.  

check_function_body=off may be what I want during the site install as the definitions should be correct in all aspects.


Thank you all
rjs


pgsql-general by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Pgpool is crashing when terminating user session
Next
From: Rob Sargent
Date:
Subject: Re: Inherited an 18TB DB & need to backup