Re: schema agnostic functions in language sql

From: Rob Sargent <robjsargent(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: 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-15 23:21:51
Message-ID: 46867210-4a1e-d066-2e63-1d3fe580a733@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 5/15/20 5:16 PM, David G. Johnston wrote:
> On Fri, May 15, 2020 at 4:07 PM Rob Sargent <robjsargent(at)gmail(dot)com
> <mailto:robjsargent(at)gmail(dot)com>> wrote:
>
> I'm terribly sorry:  I needed to add that plpgsql works without any
> knowledge of the schema, where as defining a plain sql functions does
> not work without schema qualification.
>
>
> You need to distinguish between "works" as in "compiles" and "works"
> as in "executes".
>
> Yes, SQL and pl/pgsql have very different behaviors when it comes to
> compilation and execution.  In particular SQL performs parsing earlier
> (during creation - just like it does for views) and links the textual
> query to its parse result earlier.  For pl/pgsql none of that happens
> until the function is called.  Because of this pl/pgsql allows for
> ambiguous sql text to exist and be concretely resolved during
> execution while SQL does not.
>
Thank you for the confirmation.  I'll decide whether I move to plpgsql
or dither with role/search_path in the db creation scripts.
(Both forms, plpgsql and sql, "work" once given the correct context.)
> David J.
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2020-05-15 23:41:24 Re: schema agnostic functions in language sql
Previous Message David G. Johnston 2020-05-15 23:16:54 Re: schema agnostic functions in language sql