Julien Rouhaud writes:
> On Mon, Jun 07, 2021 at 03:24:33PM -0400, Tom Lane wrote:
>> Concretely, I think the right fix is per attached.
> +1, I agree that this approach is better.
Pushed.
regards, tom lane
On Mon, Jun 07, 2021 at 03:24:33PM -0400, Tom Lane wrote:
>
> Concretely, I think the right fix is per attached.
+1, I agree that this approach is better.
On 07.06.21 17:27, Tom Lane wrote:
... I tend to agree with Julien's position here. It seems really ugly
to prohibit empty statements just for implementation convenience.
However, the way I'd handle it is to have the grammar remove them,
which is what it does in other contexts. I don't think
I wrote:
> ... I tend to agree with Julien's position here. It seems really ugly
> to prohibit empty statements just for implementation convenience.
> However, the way I'd handle it is to have the grammar remove them,
> which is what it does in other contexts.
Concretely, I think the right fix is
On Mon, Jun 7, 2021 at 11:27 PM Tom Lane wrote:
>
> Julien Rouhaud writes:
> > On Mon, Jun 7, 2021 at 4:52 PM Peter Eisentraut
> > wrote:
> >> Your patch filters out empty statements at the parse transformation
> >> phase, so they are no longer present when you dump the body back out.
> >> So yo
Julien Rouhaud writes:
> On Mon, Jun 7, 2021 at 4:52 PM Peter Eisentraut
> wrote:
>> Your patch filters out empty statements at the parse transformation
>> phase, so they are no longer present when you dump the body back out.
>> So your edits in the test expected files don't fit.
> Oh, somehow t
On Mon, Jun 7, 2021 at 4:52 PM Peter Eisentraut
wrote:
>
> Your patch filters out empty statements at the parse transformation
> phase, so they are no longer present when you dump the body back out.
> So your edits in the test expected files don't fit.
Oh, somehow the tests aren't failing here, I
On 06.06.21 09:32, Julien Rouhaud wrote:
On Sat, Jun 05, 2021 at 09:44:18PM -0700, Noah Misch wrote:
I get a NULL pointer dereference if the function body has a doubled semicolon:
create function f() returns int language sql begin atomic select 1;; end;
You don't even need a statements to
On Sat, Jun 05, 2021 at 09:44:18PM -0700, Noah Misch wrote:
> On Wed, Apr 07, 2021 at 09:55:40PM +0200, Peter Eisentraut wrote:
> > Committed. Thanks!
>
> I get a NULL pointer dereference if the function body has a doubled semicolon:
>
> create function f() returns int language sql begin atomi
On Wed, Apr 07, 2021 at 09:55:40PM +0200, Peter Eisentraut wrote:
> Committed. Thanks!
I get a NULL pointer dereference if the function body has a doubled semicolon:
create function f() returns int language sql begin atomic select 1;; end;
Program received signal SIGSEGV, Segmentation fault.
On Mon, May 10, 2021 at 11:09:43AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 27.04.21 18:16, Tom Lane wrote:
> >> That's kind of a lot of complication, and inefficiency, for a corner case
> >> that may never arise in practice. We've ignored the risk for default
> >> expressions, an
Peter Eisentraut writes:
> On 27.04.21 18:16, Tom Lane wrote:
>> That's kind of a lot of complication, and inefficiency, for a corner case
>> that may never arise in practice. We've ignored the risk for default
>> expressions, and AFAIR have yet to receive any field complaints about it.
>> So may
On 27.04.21 18:16, Tom Lane wrote:
That's kind of a lot of complication, and inefficiency, for a corner case
that may never arise in practice. We've ignored the risk for default
expressions, and AFAIR have yet to receive any field complaints about it.
So maybe it's okay to do the same for SQL-st
On 27.04.21 04:44, Justin Pryzby wrote:
On Thu, Apr 22, 2021 at 04:04:18PM -0400, Jeff Janes wrote:
This commit break line continuation prompts for unbalanced parentheses in
the psql binary. Skimming through this thread, I don't see that this is
intentional or has been noticed before.
with psq
Peter Eisentraut writes:
> On 18.04.21 23:33, Tom Lane wrote:
>> The actual use-case for that seems pretty thin, so we never bothered
>> to worry about it before. But if we're going to build loop-breaking
>> logic to handle function body dependencies, it should deal with this
>> too. I think tha
On 18.04.21 23:33, Tom Lane wrote:
... BTW, a dependency loop is also possible without using this feature,
by abusing default-value expressions:
create function f1(x int, y int) returns int language sql
as 'select $1 + $2';
create function f2(x int, y int default f1(1,2)) returns int language sq
On Thu, Apr 22, 2021 at 04:04:18PM -0400, Jeff Janes wrote:
> This commit break line continuation prompts for unbalanced parentheses in
> the psql binary. Skimming through this thread, I don't see that this is
> intentional or has been noticed before.
>
> with psql -X
>
> Before:
>
> jjanes=# a
On Wed, Apr 7, 2021 at 3:55 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
>
> Committed. Thanks!
>
>
This commit break line continuation prompts for unbalanced parentheses in
the psql binary. Skimming through this thread, I don't see that this is
intentional or has been noticed
... BTW, a dependency loop is also possible without using this feature,
by abusing default-value expressions:
create function f1(x int, y int) returns int language sql
as 'select $1 + $2';
create function f2(x int, y int default f1(1,2)) returns int language sql
as 'select $1 + $2';
create or repl
On Sun, Apr 18, 2021 at 03:08:44PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > Should we be okay releasing v14 without support for breaking function
> > dependency loops, or does that call for an open item?
>
> Oh! That should definitely be an open item. It doesn't seem
> that hard to do so
Noah Misch writes:
> Should we be okay releasing v14 without support for breaking function
> dependency loops, or does that call for an open item?
Oh! That should definitely be an open item. It doesn't seem
that hard to do something similar to what we do for views,
i.e. create a dummy function
On Tue, Jun 30, 2020 at 02:51:38PM -0400, Tom Lane wrote:
> The point remains that exposing the function body's dependencies will
> constrain restore order far more than we are accustomed to see. It
> might be possible to build examples that flat out can't be restored,
> even granting that we teac
Based on the discussion so far, I've committed 0001 and 0002 but not 0003,
and marked this open issue as closed.
regards, tom lane
>
> > This is nice. Are there any parallelism capabilities?
>
> Yes. It defaults to number-of-cores processes, but obviously can also be
> specified explicitly. One very nice part about it is that it'd work
> largely the same on windows (which has practically unusable testing
> right now). It prob
On Sat, Apr 10, 2021 at 10:52:15AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Fri, Apr 09, 2021 at 12:09:43PM -0400, Tom Lane wrote:
> >> The real value of 0003 of course would be to get an error cursor at
> >> runtime
>
> > A key benefit of $SUBJECT is the function body following DDL ren
Noah Misch writes:
> On Fri, Apr 09, 2021 at 12:09:43PM -0400, Tom Lane wrote:
>> The real value of 0003 of course would be to get an error cursor at
>> runtime
> A key benefit of $SUBJECT is the function body following DDL renames:
Agreed. But ...
> After the rename, any stored prosrc is obso
On Fri, Apr 09, 2021 at 12:09:43PM -0400, Tom Lane wrote:
> Finally, 0003 might be a bit controversial: it changes the stored
> prosrc for new-style SQL functions to be the query text of the CREATE
> FUNCTION command. The main argument I can see being made against this
> is that it'll bloat the pg
On 4/9/21 12:09 PM, Tom Lane wrote:
> One could make an argument, therefore, for holding off 0003 until
> there's more support for execution-time error cursors. I don't
> think we should though, for two reasons:
> 1. It'd be better to keep the pg_proc representation of new-style
> SQL functions
Julien Rouhaud writes:
> On Thu, Apr 08, 2021 at 04:54:56PM +0900, Michael Paquier wrote:
>> Indeed, I agree that enforcing the availability of querystring
>> everywhere sounds like a sensible thing to do in terms of consistency,
>> and that's my impression when I scanned the parallel execution co
Hi,
On 2021-04-09 08:39:46 +0900, Michael Paquier wrote:
> On Thu, Apr 08, 2021 at 10:50:39AM -0700, Andres Freund wrote:
> > Obviously all very far from being ready, but this seemed like a good
> > enough excuse to mention it ;)
>
> This is nice. Are there any parallelism capabilities?
Yes. It
On Thu, Apr 08, 2021 at 10:50:39AM -0700, Andres Freund wrote:
> Obviously all very far from being ready, but this seemed like a good
> enough excuse to mention it ;)
This is nice. Are there any parallelism capabilities?
--
Michael
signature.asc
Description: PGP signature
On Thu, Apr 08, 2021 at 12:21:05PM -0400, Tom Lane wrote:
> I see that contrib/test_decoding also sets NO_INSTALLCHECK = 1,
> and the reason it gets tested is that the buildfarm script has
> a special module for that. I guess we need to clone that module,
> or maybe better, find a way to generaliz
On 2021-04-08 10:50:39 -0700, Andres Freund wrote:
> It's hard to convey just how much nicer it is to see a progress report
> during the test, see the failing tests at the end, without needing to
> wade through reams of log output. The output of the individual tests is
> in testlog.txt referenced
Hi,
This started out as a reply to
https://postgr.es/m/20210408170802.GA9392%40alvherre.pgsql
but it's independent enough to just start a new thread...
On 2021-04-08 13:08:02 -0400, Alvaro Herrera wrote:
> Yes, coverage.pg.org runs "make check-world".
>
> Maybe it would make sense to change that
On 2021-Apr-08, Julien Rouhaud wrote:
> On Thu, Apr 08, 2021 at 02:58:02AM -0400, Tom Lane wrote:
> > No, because if that were the explanation then we'd be getting no
> > buildfarm coverage at all for for pg_stat_statements. Which aside
> > from being awful contradicts the results at coverage.po
On 4/8/21 2:40 AM, Julien Rouhaud wrote:
> On Wed, Apr 07, 2021 at 11:33:20PM -0700, Andres Freund wrote:
>> Hi,
>>
>> On 2021-04-08 02:05:25 -0400, Tom Lane wrote:
>>> So far the buildfarm seems to be turning green after b3ee4c503 ...
>>> so I wonder what extra condition is needed to cause the f
Julien Rouhaud writes:
> On Thu, Apr 08, 2021 at 02:58:02AM -0400, Tom Lane wrote:
>> No, because if that were the explanation then we'd be getting no
>> buildfarm coverage at all for for pg_stat_statements. Which aside
>> from being awful contradicts the results at coverage.postgresql.org.
> Is
On Thu, Apr 08, 2021 at 02:58:02AM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > On Wed, Apr 07, 2021 at 11:33:20PM -0700, Andres Freund wrote:
> >> Nothing special, really. Surprised the BF doesn't see it:
>
> > Is think this is because the buildfarm client is running installcheck for
> >
On Thu, Apr 08, 2021 at 04:54:56PM +0900, Michael Paquier wrote:
> On Wed, Apr 07, 2021 at 11:35:14PM -0700, Andres Freund wrote:
> > On 2021-04-08 01:41:40 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >> FWIW, I think the long-term drift of things is definitely that
> >> we want to have th
On Wed, Apr 07, 2021 at 11:35:14PM -0700, Andres Freund wrote:
> On 2021-04-08 01:41:40 -0400, Tom Lane wrote:
>> Andres Freund writes:
>> FWIW, I think the long-term drift of things is definitely that
>> we want to have the querystring available everywhere. Code like
>> executor_errposition is f
Julien Rouhaud writes:
> On Wed, Apr 07, 2021 at 11:33:20PM -0700, Andres Freund wrote:
>> Nothing special, really. Surprised the BF doesn't see it:
> Is think this is because the buildfarm client is running installcheck for the
> contribs rather than check, and pg_stat_statements/Makefile has:
>
On Wed, Apr 07, 2021 at 11:33:20PM -0700, Andres Freund wrote:
> Hi,
>
> On 2021-04-08 02:05:25 -0400, Tom Lane wrote:
> > So far the buildfarm seems to be turning green after b3ee4c503 ...
> > so I wonder what extra condition is needed to cause the failure
> > Andres is seeing.
>
> Nothing speci
Hi,
On 2021-04-08 01:41:40 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Independent of this patch, it might be a good idea to have
> > ExecInitParallelPlan() be robust against NULL querystrings. Places like
> > executor_errposition() are certainly trying to be...
>
> FWIW, I think the long
Hi,
On 2021-04-08 02:05:25 -0400, Tom Lane wrote:
> So far the buildfarm seems to be turning green after b3ee4c503 ...
> so I wonder what extra condition is needed to cause the failure
> Andres is seeing.
Nothing special, really. Surprised the BF doesn't see it:
andres@awork3:~/build/postgres/de
Julien Rouhaud writes:
> On Wed, Apr 07, 2021 at 10:27:59PM -0700, Andres Freund wrote:
>> One holdup was that
>> check-world didn't succeed with force_parallel_mode=regress even after
>> the fix - but that turned out to be the fault of
Move pg_stat_statements query jumbling to core.
> Yep,
On Wed, Apr 07, 2021 at 10:27:59PM -0700, Andres Freund wrote:
>
> One holdup was that
> check-world didn't succeed with force_parallel_mode=regress even after
> the fix - but that turned out to be the fault of
>
> commit 5fd9dfa5f50e4906c35133a414ebec5b6d518493 (HEAD)
> Author: Bruce Momjian
>
Andres Freund writes:
> Independent of this patch, it might be a good idea to have
> ExecInitParallelPlan() be robust against NULL querystrings. Places like
> executor_errposition() are certainly trying to be...
FWIW, I think the long-term drift of things is definitely that
we want to have the qu
Hi,
On 2021-04-08 01:16:02 -0400, Tom Lane wrote:
> Michael Paquier writes:
> > On Wed, Apr 07, 2021 at 04:22:17PM -0400, Tom Lane wrote:
> >> Buildfarm suggests this has some issues under force_parallel_mode.
> >> I'm wondering about missed fields in outfuncs/readfuncs, or the like.
>
> > The pr
Michael Paquier writes:
> On Wed, Apr 07, 2021 at 04:22:17PM -0400, Tom Lane wrote:
>> Buildfarm suggests this has some issues under force_parallel_mode.
>> I'm wondering about missed fields in outfuncs/readfuncs, or the like.
> The problem looks a bit more fundamental to me, as there seems to be
On Wed, Apr 07, 2021 at 04:22:17PM -0400, Tom Lane wrote:
> Buildfarm suggests this has some issues under force_parallel_mode.
> I'm wondering about missed fields in outfuncs/readfuncs, or the like.
The problem looks a bit more fundamental to me, as there seems to be
some confusion with the concep
Peter Eisentraut writes:
> Committed. Thanks!
Buildfarm suggests this has some issues under force_parallel_mode.
I'm wondering about missed fields in outfuncs/readfuncs, or the like.
regards, tom lane
On 03.04.21 05:39, Julien Rouhaud wrote:
Are you planning to run pg_indent before committing or would that add too much
noise?
Yeah, I figured I'd leave that for later, to not bloat the patch so much.
Anyway since it's only stylistic issues and the feature freeze is getting
closer I'm marking
On Fri, Apr 02, 2021 at 02:25:15PM +0200, Peter Eisentraut wrote:
>
> New patch attached.
Thanks, it all looks good to me. I just spot a few minor formatting issues:
@@ -2968,6 +2973,13 @@ pg_get_functiondef(PG_FUNCTION_ARGS)
}
/* And finally the function definition ... */
+ tmp = Sy
On 31.03.21 12:12, Julien Rouhaud wrote:
On Tue, Mar 23, 2021 at 11:28:55PM -0500, Jaime Casanova wrote:
On Fri, Mar 19, 2021 at 8:49 AM Peter Eisentraut
wrote:
Right. Here is a new patch with that fix added and a small conflict
resolved.
Great.
It seems print_function_sqlbody() is not pr
On Tue, Mar 23, 2021 at 11:28:55PM -0500, Jaime Casanova wrote:
> On Fri, Mar 19, 2021 at 8:49 AM Peter Eisentraut
> wrote:
> >
> > Right. Here is a new patch with that fix added and a small conflict
> > resolved.
>
> Great.
>
> It seems print_function_sqlbody() is not protected to avoid receiv
On Fri, Mar 19, 2021 at 8:49 AM Peter Eisentraut
wrote:
>
> Right. Here is a new patch with that fix added and a small conflict
> resolved.
Great.
It seems print_function_sqlbody() is not protected to avoid receiving
a function that hasn't a standard sql body in
src/backend/utils/adt/ruleutils.
On 15.03.21 09:14, Julien Rouhaud wrote:
On Mon, Mar 15, 2021 at 04:03:44PM +0800, Julien Rouhaud wrote:
On Mon, Mar 15, 2021 at 01:05:11AM -0500, Jaime Casanova wrote:
I found another problem when using CASE expressions:
CREATE OR REPLACE FUNCTION foo_case()
RETURNS boolean
LANGUAGE SQL
BEGIN
On Mon, Mar 15, 2021 at 04:03:44PM +0800, Julien Rouhaud wrote:
> On Mon, Mar 15, 2021 at 01:05:11AM -0500, Jaime Casanova wrote:
> > I found another problem when using CASE expressions:
> >
> > CREATE OR REPLACE FUNCTION foo_case()
> > RETURNS boolean
> > LANGUAGE SQL
> > BEGIN ATOMIC
> > sel
On Mon, Mar 15, 2021 at 01:05:11AM -0500, Jaime Casanova wrote:
> I found another problem when using CASE expressions:
>
> CREATE OR REPLACE FUNCTION foo_case()
> RETURNS boolean
> LANGUAGE SQL
> BEGIN ATOMIC
> select case when random() > 0.5 then true else false end;
> END;
>
> apparently th
On Tue, Mar 9, 2021 at 7:27 AM Peter Eisentraut
wrote:
>
>
> I see. The problem is that we don't have serialization and
> deserialization support for most utility statements. I think I'll need
> to add that eventually. For now, I have added code to prevent utility
> statements. I think it's st
On 05.03.21 06:58, Jaime Casanova wrote:
I was making some tests with this patch and found this problem:
"""
CREATE OR REPLACE FUNCTION public.make_table()
RETURNS void
LANGUAGE sql
BEGIN ATOMIC
CREATE TABLE created_table AS SELECT * FROM int8_tbl;
END;
ERROR: unrecognized token: "?"
CON
On Tue, Mar 2, 2021 at 12:13 PM Peter Eisentraut
wrote:
>
> On 11.02.21 09:02, Peter Eisentraut wrote:
> >> Here is an updated patch to get it building again.
> >
> > Another updated patch to get things building again. I've also fixed the
> > last TODO I had in there in qualifying function argume
On 11.02.21 09:02, Peter Eisentraut wrote:
Here is an updated patch to get it building again.
Another updated patch to get things building again. I've also fixed the
last TODO I had in there in qualifying function arguments as necessary
in ruleutils.c.
Updated patch to resolve merge confli
On 2020-11-20 08:25, Peter Eisentraut wrote:
On 2020-11-10 16:21, Georgios Kokolatos wrote:
Hi,
I noticed that this patch fails on the cfbot.
For this, I changed the status to: 'Waiting on Author'.
Cheers,
//Georgios
The new status of this patch is: Waiting on Author
Here is an updated pat
On 2020-11-10 16:21, Georgios Kokolatos wrote:
Hi,
I noticed that this patch fails on the cfbot.
For this, I changed the status to: 'Waiting on Author'.
Cheers,
//Georgios
The new status of this patch is: Waiting on Author
Here is an updated patch to get it building again.
--
Peter Eisentr
Hi,
I noticed that this patch fails on the cfbot.
For this, I changed the status to: 'Waiting on Author'.
Cheers,
//Georgios
The new status of this patch is: Waiting on Author
Here is another updated patch. I did some merging and some small fixes
and introduced the pg_proc column prosqlbody to store the parsed
function body separately from probin. Aside from one TODO left it seems
feature-complete to me for now.
--
Peter Eisentraut http://www.2ndQuadr
On 2020-09-29 07:42, Michael Paquier wrote:
On Mon, Sep 07, 2020 at 08:00:08AM +0200, Peter Eisentraut wrote:
Some conflicts have emerged, so here is an updated patch.
I have implemented/fixed the inlining of set-returning functions written in
the new style, which was previously marked TODO in
On Mon, Sep 07, 2020 at 08:00:08AM +0200, Peter Eisentraut wrote:
> Some conflicts have emerged, so here is an updated patch.
>
> I have implemented/fixed the inlining of set-returning functions written in
> the new style, which was previously marked TODO in the patch.
The CF bot is telling that
Some conflicts have emerged, so here is an updated patch.
I have implemented/fixed the inlining of set-returning functions written
in the new style, which was previously marked TODO in the patch.
On 2020-08-28 07:33, Peter Eisentraut wrote:
On 2020-06-30 19:49, Peter Eisentraut wrote:
This
On 2020-06-30 19:49, Peter Eisentraut wrote:
This adds support for writing CREATE FUNCTION and CREATE PROCEDURE
statements for language SQL with a function body that conforms to the
SQL standard and is portable to other implementations.
Here is a new patch. The only significant change is that
Thomas Munro writes:
> On Wed, Jul 1, 2020 at 5:49 AM Peter Eisentraut
> wrote:
>> - More test coverage is needed. Surprisingly, there wasn't actually any
>> test AFAICT that just creates and SQL function and runs it. Most of
>> that code is tested incidentally, but there is very little or no
>
On Wed, Jul 1, 2020 at 5:49 AM Peter Eisentraut
wrote:
> - More test coverage is needed. Surprisingly, there wasn't actually any
> test AFAICT that just creates and SQL function and runs it. Most of
> that code is tested incidentally, but there is very little or no
> targeted testing of this fun
st 1. 7. 2020 v 22:54 odesílatel Vik Fearing
napsal:
> On 7/1/20 10:34 PM, Pavel Stehule wrote:
> > st 1. 7. 2020 v 22:31 odesílatel Vik Fearing
> > napsal:
> >
> >> On 7/1/20 9:32 PM, Pavel Stehule wrote:
> >>> st 1. 7. 2020 v 20:19 odesílatel Vik Fearing
> >>> napsal:
> >>>
> On 7/1/20 3
Thomas Munro writes:
> On Wed, Jul 1, 2020 at 5:58 AM Robert Haas wrote:
>> With what other implementations is it compatible?
> Judging by the Wikipedia article[1], it sounds like at least DB2 and
> MySQL/MariaDB are purposely striving for conformance.
> [1] https://en.wikipedia.org/wiki/SQL/PSM
On Wed, Jul 1, 2020 at 5:58 AM Robert Haas wrote:
> On Tue, Jun 30, 2020 at 1:49 PM Peter Eisentraut
> wrote:
> > This adds support for writing CREATE FUNCTION and CREATE PROCEDURE
> > statements for language SQL with a function body that conforms to the
> > SQL standard and is portable to other
st 1. 7. 2020 v 22:54 odesílatel Vik Fearing
napsal:
> On 7/1/20 10:34 PM, Pavel Stehule wrote:
> > st 1. 7. 2020 v 22:31 odesílatel Vik Fearing
> > napsal:
> >
> >> On 7/1/20 9:32 PM, Pavel Stehule wrote:
> >>> st 1. 7. 2020 v 20:19 odesílatel Vik Fearing
> >>> napsal:
> >>>
> On 7/1/20 3
On 7/1/20 10:34 PM, Pavel Stehule wrote:
> st 1. 7. 2020 v 22:31 odesílatel Vik Fearing
> napsal:
>
>> On 7/1/20 9:32 PM, Pavel Stehule wrote:
>>> st 1. 7. 2020 v 20:19 odesílatel Vik Fearing
>>> napsal:
>>>
On 7/1/20 3:36 PM, Robert Haas wrote:
> I actually don't have a very clear idea
st 1. 7. 2020 v 22:31 odesílatel Vik Fearing
napsal:
> On 7/1/20 9:32 PM, Pavel Stehule wrote:
> > st 1. 7. 2020 v 20:19 odesílatel Vik Fearing
> > napsal:
> >
> >> On 7/1/20 3:36 PM, Robert Haas wrote:
> >>> I actually don't have a very clear idea of what the standard has to
> >>> say about SQL
On 7/1/20 9:32 PM, Pavel Stehule wrote:
> st 1. 7. 2020 v 20:19 odesílatel Vik Fearing
> napsal:
>
>> On 7/1/20 3:36 PM, Robert Haas wrote:
>>> I actually don't have a very clear idea of what the standard has to
>>> say about SQL-language functions. Does it just say it's a list of
>>> statements,
st 1. 7. 2020 v 20:19 odesílatel Vik Fearing
napsal:
> On 7/1/20 3:36 PM, Robert Haas wrote:
> > I actually don't have a very clear idea of what the standard has to
> > say about SQL-language functions. Does it just say it's a list of
> > statements, or does it involve variables and control-flow
On 7/1/20 3:36 PM, Robert Haas wrote:
> I actually don't have a very clear idea of what the standard has to
> say about SQL-language functions. Does it just say it's a list of
> statements, or does it involve variables and control-flow constructs
> and stuff like that, too?
It's either a single s
Bruce Momjian writes:
> Is the SQL-standard function body verified as preventing function
> inlining? That seems to be a major downside.
I see no reason why that would make any difference. There might
be more code to be written than is in the patch, but in principle
inlining should not care whe
On Wed, Jul 1, 2020 at 10:14:10AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > In my experience, there's certainly demand for some kind of mode where
> > plpgsql functions get checked at function definition time, rather than
> > at execution time.
>
> Yeah, absolutely agreed. But I'm afraid
st 1. 7. 2020 v 16:14 odesílatel Tom Lane napsal:
> Robert Haas writes:
> > In my experience, there's certainly demand for some kind of mode where
> > plpgsql functions get checked at function definition time, rather than
> > at execution time.
>
> Yeah, absolutely agreed. But I'm afraid this p
Robert Haas writes:
> In my experience, there's certainly demand for some kind of mode where
> plpgsql functions get checked at function definition time, rather than
> at execution time.
Yeah, absolutely agreed. But I'm afraid this proposal takes us too
far in the other direction: with this, you
st 1. 7. 2020 v 15:37 odesílatel Robert Haas napsal:
> On Tue, Jun 30, 2020 at 2:51 PM Tom Lane wrote:
> > On further thought, we probably don't have to. Re-parsing the function
> > body the same way is exactly the same problem as re-parsing a view or
> > matview body the same way. I don't wan
On Tue, Jun 30, 2020 at 2:51 PM Tom Lane wrote:
> On further thought, we probably don't have to. Re-parsing the function
> body the same way is exactly the same problem as re-parsing a view or
> matview body the same way. I don't want to claim that that's a 100%
> solved problem, but I've heard
Andres Freund writes:
> On 2020-06-30 19:49:04 +0200, Peter Eisentraut wrote:
>> The function body is parsed at function definition time and stored as
>> expression nodes in probin. So at run time, no further parsing is
>> required.
> Isn't a consequence of that that we'd get a lot more errors i
Hi,
On 2020-06-30 19:49:04 +0200, Peter Eisentraut wrote:
> The function body is parsed at function definition time and stored as
> expression nodes in probin. So at run time, no further parsing is
> required.
As raw parse tree or as a parse-analysed tree? I assume the latter?
Isn't a consequen
I wrote:
> Replicating the creation-time search path will be a big headache for
> pg_dump, I bet.
On further thought, we probably don't have to. Re-parsing the function
body the same way is exactly the same problem as re-parsing a view or
matview body the same way. I don't want to claim that tha
Robert Haas writes:
> On Tue, Jun 30, 2020 at 1:49 PM Peter Eisentraut
> wrote:
>> This adds support for writing CREATE FUNCTION and CREATE PROCEDURE
>> statements for language SQL with a function body that conforms to the
>> SQL standard and is portable to other implementations.
> With what oth
út 30. 6. 2020 v 19:58 odesílatel Robert Haas
napsal:
> On Tue, Jun 30, 2020 at 1:49 PM Peter Eisentraut
> wrote:
> > This adds support for writing CREATE FUNCTION and CREATE PROCEDURE
> > statements for language SQL with a function body that conforms to the
> > SQL standard and is portable to o
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> Hmm, this all seems like a pretty big semantic change. IIUC, right
> now, a SQL function can only contain one statement, but it seems like
> with this patch you can have a block in there with a bunch of
> statements, sorta like plpgsql.
Fr
On Tue, Jun 30, 2020 at 1:49 PM Peter Eisentraut
wrote:
> This adds support for writing CREATE FUNCTION and CREATE PROCEDURE
> statements for language SQL with a function body that conforms to the
> SQL standard and is portable to other implementations.
With what other implementations is it compa
95 matches
Mail list logo
