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
2021 14:23:14 +0200
Subject: [PATCH v11] SQL-standard function body
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.
Instead of the PostgreSQL-specific AS $$ st
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.
00:00:00 2001
From: Peter Eisentraut
Date: Fri, 19 Mar 2021 14:48:04 +0100
Subject: [PATCH v10] SQL-standard function body
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 im
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
utility
statements. I think it's still useful that way for now.
From 29de4ec1ae12d3f9c1f6a31cf626a19b2421ae7a Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 9 Mar 2021 13:25:39 +0100
Subject: [PATCH v9] SQL-standard function body
This adds support for writing CREATE FUNCTION and
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
merge conflict. No changes in functionality.
From 8e61da555d6083f9ec0f90791b02082376fe010b Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 2 Mar 2021 18:08:15 +0100
Subject: [PATCH v8] SQL-standard function body
This adds support for writing CREATE FUNCTION and CREATE PROCEDURE
statement
drant.com/
From 5204b882417e4a3c35f93bc8d22ea066c079a10e Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Thu, 11 Feb 2021 08:57:29 +0100
Subject: [PATCH v7] SQL-standard function body
This adds support for writing CREATE FUNCTION and CREATE PROCEDURE
statements for language SQL with a function body that conf
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
From 5fa3855abd88e0174cb00308a996819440b7e6b9 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Fri, 20 Nov 2020 08:23:30 +0100
Subject: [PATCH v6] SQL-standard function body
This adds support for writing CREATE FUNCTION
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
.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 566a30b33df2bca79dd7c6f45f2f55be42403b27 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 27 Oct 2020 14:40:14 +0100
Subject: [PATCH v5] SQL-standard function body
This adds support for writing
reSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 14be6cb14759636b407f89cee50fa2896ee98f5d Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Sat, 10 Oct 2020 10:36:28 +0200
Subject: [PATCH v4] SQL-standard function body
This adds support for writing CREATE FUNCTIO
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
Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 7 Sep 2020 07:55:35 +0200
Subject: [PATCH v3] SQL-standard function body
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
ining & Services
From 4df3c9db684cd1de6c9bfa622829308a4f8809a7 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Fri, 28 Aug 2020 07:19:10 +0200
Subject: [PATCH v2] SQL-standard function body
This adds support for writing CREATE FUNCTION and CREATE PROCEDURE
statements for language SQL with a func
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 no
ld
> stop doing analysis as soon as it finds a DDL command?
Is the SQL-standard function body verified as preventing function
inlining? That seems to be a major downside.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
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
ideas are solidified.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 9611034103216bf57a76546cc212786fa8fe5b73 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 30 Jun 2020 19:42:08 +0200
Subject:
96 matches
Mail list logo
