Re: schema agnostic functions in language sql

From: Rob Sargent <robjsargent(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: schema agnostic functions in language sql
Date: 2020-05-16 12:15:22
Message-ID: 01AD9083-259E-4F92-85E8-8A254E89716C@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> On May 15, 2020, at 6:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Rob Sargent <robjsargent(at)gmail(dot)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. Looking back, 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rob Sargent 2020-05-16 12:18:23 Re: Inherited an 18TB DB & need to backup
Previous Message Tatsuo Ishii 2020-05-16 11:55:15 Re: Pgpool is crashing when terminating user session