Re: schema agnostic functions in language sql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Rob Sargent <robjsargent(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-15 23:41:24
Message-ID: 17840.1589586084@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> 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.

I don't think that's accurate. SQL functions are stored as plain text,
just like any other non-C-coded function, and they are not parsed until
execution.

There are big differences from plpgsql of course. For one, it's
possible for a SQL function to be "inlined" into the calling query,
in which case parsing happens during planning of the calling query.
But other than that, I'd expect the execution-time search path
to determine how a SQL function behaves.

Since Rob didn't provide any details, it's far from clear what's
going wrong for him.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rob Sargent 2020-05-15 23:58:46 Re: schema agnostic functions in language sql
Previous Message Rob Sargent 2020-05-15 23:21:51 Re: schema agnostic functions in language sql