Hi
so 25. 5. 2024 v 3:29 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > we can introduce special safe mode started by
> > set enable_direct_variable_read to off;
> > and allowing access to variables only by usage dedicated function
> > (supported by parser) named like variable or
so 25. 5. 2024 v 10:24 odesílatel napsal:
> Pavel Stehule:
> > Sure there is more possibilities, but I don't want to lost the
> > possibility to write code like
> >
> > CREATE TEMP VARIABLE _x;
> >
> > LET _x = 'hello';
> >
> > DO $$
> > BEGIN
> >RAISE NOTICE '%', _x;
> > END;
> > $$;
> >
>
Pavel Stehule:
Sure there is more possibilities, but I don't want to lost the
possibility to write code like
CREATE TEMP VARIABLE _x;
LET _x = 'hello';
DO $$
BEGIN
RAISE NOTICE '%', _x;
END;
$$;
So I am searching for a way to do it safely, but still intuitive and
user friendly.
Maybe
so 25. 5. 2024 v 3:29 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > we can introduce special safe mode started by
> > set enable_direct_variable_read to off;
> > and allowing access to variables only by usage dedicated function
> > (supported by parser) named like variable or
Pavel Stehule writes:
> we can introduce special safe mode started by
> set enable_direct_variable_read to off;
> and allowing access to variables only by usage dedicated function
> (supported by parser) named like variable or pg_variable
Didn't we learn twenty years ago that GUCs that change
Hi
st 22. 5. 2024 v 19:25 odesílatel Tom Lane napsal:
> Peter Eisentraut writes:
> > On 18.05.24 13:29, Alvaro Herrera wrote:
> >> I want to note that when we discussed this patch series at the dev
> >> meeting in FOSDEM, a sort-of conclusion was reached that we didn't want
> >> schema
>
>
>
>
>>
>> As far as I can see now, it's a major design flaw that could keep the
>> patch from being accepted. Fortunately there are few good proposals how
>> to address this, folks are genuinely trying to help. What do you think
>> about trying some of them out, as an alternative approach, to
Hi
pá 24. 5. 2024 v 13:32 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, May 22, 2024 at 08:44:28PM +0200, Pavel Stehule wrote:
> > st 22. 5. 2024 v 19:25 odesílatel Tom Lane napsal:
> >
> > > Peter Eisentraut writes:
> > > > On 18.05.24 13:29, Alvaro Herrera wrote:
> > >
> On Wed, May 22, 2024 at 08:44:28PM +0200, Pavel Stehule wrote:
> st 22. 5. 2024 v 19:25 odesílatel Tom Lane napsal:
>
> > Peter Eisentraut writes:
> > > On 18.05.24 13:29, Alvaro Herrera wrote:
> > >> I want to note that when we discussed this patch series at the dev
> > >> meeting in FOSDEM,
Hi
st 22. 5. 2024 v 16:14 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, May 22, 2024 at 02:37:49PM +0200, Peter Eisentraut wrote:
> > On 18.05.24 13:29, Alvaro Herrera wrote:
> > > I want to note that when we discussed this patch series at the dev
> > > meeting in FOSDEM,
st 22. 5. 2024 v 14:37 odesílatel Peter Eisentraut
napsal:
> On 18.05.24 13:29, Alvaro Herrera wrote:
> > I want to note that when we discussed this patch series at the dev
> > meeting in FOSDEM, a sort-of conclusion was reached that we didn't want
> > schema variables at all because of the fact
st 22. 5. 2024 v 20:21 odesílatel napsal:
> Alvaro Herrera:
> > Perhaps the solution to all this is to avoid having the variables be
> > implicitly present in the range table of all queries. Instead, if you
> > need a variable's value, then you need to add the variable to the FROM
> > clause;
>
st 22. 5. 2024 v 19:25 odesílatel Tom Lane napsal:
> Peter Eisentraut writes:
> > On 18.05.24 13:29, Alvaro Herrera wrote:
> >> I want to note that when we discussed this patch series at the dev
> >> meeting in FOSDEM, a sort-of conclusion was reached that we didn't want
> >> schema variables
st 22. 5. 2024 v 14:37 odesílatel Peter Eisentraut
napsal:
> On 18.05.24 13:29, Alvaro Herrera wrote:
> > I want to note that when we discussed this patch series at the dev
> > meeting in FOSDEM, a sort-of conclusion was reached that we didn't want
> > schema variables at all because of the fact
Alvaro Herrera:
Perhaps the solution to all this is to avoid having the variables be
implicitly present in the range table of all queries. Instead, if you
need a variable's value, then you need to add the variable to the FROM
clause;
+1
This should make it easier to work with composite type
On 2024-May-22, Dmitry Dolgov wrote:
> Yeah, that's a bummer. Interestingly enough, the db2 implementation of
> global session variables mechanism is mentioned as similar to what we
> have in the patch. But weirdly, the db2 documentation just states
> possibility of a resolution conflict for
Peter Eisentraut writes:
> On 18.05.24 13:29, Alvaro Herrera wrote:
>> I want to note that when we discussed this patch series at the dev
>> meeting in FOSDEM, a sort-of conclusion was reached that we didn't want
>> schema variables at all because of the fact that creating a variable
>> would
> On Wed, May 22, 2024 at 02:37:49PM +0200, Peter Eisentraut wrote:
> On 18.05.24 13:29, Alvaro Herrera wrote:
> > I want to note that when we discussed this patch series at the dev
> > meeting in FOSDEM, a sort-of conclusion was reached that we didn't want
> > schema variables at all because of
On 18.05.24 13:29, Alvaro Herrera wrote:
I want to note that when we discussed this patch series at the dev
meeting in FOSDEM, a sort-of conclusion was reached that we didn't want
schema variables at all because of the fact that creating a variable
would potentially change the meaning of queries
so 18. 5. 2024 v 18:31 odesílatel Alvaro Herrera
napsal:
> On 2024-Jan-30, Dmitry Dolgov wrote:
>
> > Yep, in this constellation the implementation holds much better (in
> > terms of memory) in my create/let/drop testing.
> >
> > I've marked the CF item as ready for committer, but a note for
On 2024-Jan-30, Dmitry Dolgov wrote:
> Yep, in this constellation the implementation holds much better (in
> terms of memory) in my create/let/drop testing.
>
> I've marked the CF item as ready for committer, but a note for anyone
> who would like to pick up it from here -- we're talking about
út 30. 1. 2024 v 20:15 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> Yep, in this constellation the implementation holds much better (in
> terms of memory) in my create/let/drop testing.
>
> I've marked the CF item as ready for committer, but a note for anyone
> who would like to
Yep, in this constellation the implementation holds much better (in
terms of memory) in my create/let/drop testing.
I've marked the CF item as ready for committer, but a note for anyone
who would like to pick up it from here -- we're talking about first 5
patches here, up to the memory cleaning
po 29. 1. 2024 v 19:36 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Mon, Jan 29, 2024 at 08:57:42AM +0100, Pavel Stehule wrote:
> > Hi
> >
> > ne 28. 1. 2024 v 19:00 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> > napsal:
> >
> > > Thanks for the update, smaller patches
> On Mon, Jan 29, 2024 at 08:57:42AM +0100, Pavel Stehule wrote:
> Hi
>
> ne 28. 1. 2024 v 19:00 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
> > Thanks for the update, smaller patches looks promising.
> >
> > Off the list Pavel has mentioned that the first two patches contain a
>
> On Sun, Jan 28, 2024 at 08:34:40PM +0100, Pavel Stehule wrote:
> > * I've noticed an interesting result when a LET statement is used to
> > assign a
> > value without a subquery:
> >
> > create variable test as text;
> > -- returns NULL
> > select test;
> >
> >
ne 28. 1. 2024 v 19:00 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> Thanks for the update, smaller patches looks promising.
>
> Off the list Pavel has mentioned that the first two patches contain a
> bare minimum for session variables, so I've reviewed them once more and
> suggest
Thanks for the update, smaller patches looks promising.
Off the list Pavel has mentioned that the first two patches contain a
bare minimum for session variables, so I've reviewed them once more and
suggest to concentrate on them first. I'm afraid the memory cleanup
patch has to be added to the
> On Sun, Dec 03, 2023 at 06:04:12AM +0100, Pavel Stehule wrote:
>
> Thank you for your review. Next two weeks I'll not too much time to work
> on this patch - I have to work on some commercial work, and the week is
> Prague PgConf, so my reply will be slow. But after these events I'll
>
Hi
ne 26. 11. 2023 v 18:56 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Sat, Nov 18, 2023 at 06:28:53PM +0100, Pavel Stehule wrote:
> > so 18. 11. 2023 v 15:54 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> > napsal:
> > > As a side note, I'm intended to go one more time
Hi
st 22. 11. 2023 v 7:20 odesílatel Julien Rouhaud
napsal:
> Hi,
>
> On Tue, Oct 17, 2023 at 08:52:13AM +0200, Pavel Stehule wrote:
> >
> > When I thought about global temporary tables, I got one maybe interesting
> > idea. The one significant problem of global temporary tables is place for
>
> On Sat, Nov 18, 2023 at 06:28:53PM +0100, Pavel Stehule wrote:
> so 18. 11. 2023 v 15:54 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
> > As a side note, I'm intended to go one more time through the first few
> > patches introducing the basic functionality, and then mark it as
Hi,
On Tue, Oct 17, 2023 at 08:52:13AM +0200, Pavel Stehule wrote:
>
> When I thought about global temporary tables, I got one maybe interesting
> idea. The one significant problem of global temporary tables is place for
> storing info about size or column statistics.
>
> I think so these data
> On Sat, Nov 18, 2023 at 02:19:09PM +0100, Pavel Stehule wrote:
> > Would it be a problem to make pg_session_variables inspect the catalog
> > or something similar if needed?
> >
>
> It can be very easy to build pg_session_variables based on iteration over
> the system catalog. But I am not sure
>>
>> The difference between debug_parallel_query = 1 and debug_parallel_query
>> = 0 is strange - and I'll check it.
>>
>
> looks so pg_session_variables() doesn't work in debug_paralel_query mode.
>
It is marked as parallel safe, what is probably nonsense.
so 18. 11. 2023 v 14:19 odesílatel Pavel Stehule
napsal:
> Hi
>
> pá 17. 11. 2023 v 20:17 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
>> > On Wed, Aug 23, 2023 at 04:02:44PM +0200, Pavel Stehule wrote:
>> > NameListToString is already buildin function. Do you think
>>
Hi
pá 17. 11. 2023 v 20:17 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, Aug 23, 2023 at 04:02:44PM +0200, Pavel Stehule wrote:
> > NameListToString is already buildin function. Do you think NamesFromList?
> >
> > This is my oversight - there is just `+extern List
> On Wed, Aug 23, 2023 at 04:02:44PM +0200, Pavel Stehule wrote:
> NameListToString is already buildin function. Do you think NamesFromList?
>
> This is my oversight - there is just `+extern List *NamesFromList(List
> *names); ` line, but sure - it should be in 0002 patch
>
> fixed now
Right,
Hi
When I thought about global temporary tables, I got one maybe interesting
idea. The one significant problem of global temporary tables is place for
storing info about size or column statistics.
I think so these data can be stored simply in session variables. Any global
temporary table can get
On Sat, Aug 12, 2023 at 01:20:03PM +0200, Dmitry Dolgov wrote:
> > On Sat, Aug 12, 2023 at 09:28:19AM +0800, Julien Rouhaud wrote:
> > On Fri, Aug 11, 2023 at 05:55:26PM +0200, Dmitry Dolgov wrote:
> > >
> > > Another confusing example was this one at the end of set_session_variable:
> > >
> > >
> On Sat, Aug 12, 2023 at 09:28:19AM +0800, Julien Rouhaud wrote:
> On Fri, Aug 11, 2023 at 05:55:26PM +0200, Dmitry Dolgov wrote:
> >
> > Another confusing example was this one at the end of set_session_variable:
> >
> > + /*
> > +* XXX While unlikely, an error here is
On Fri, Aug 11, 2023 at 05:55:26PM +0200, Dmitry Dolgov wrote:
>
> Another confusing example was this one at the end of set_session_variable:
>
> + /*
> + * XXX While unlikely, an error here is possible. It wouldn't leak
> memory
> + * as the allocated chunk has already been
> On Thu, Aug 03, 2023 at 08:15:13AM +0200, Pavel Stehule wrote:
> Hi
>
> fresh rebase
Thanks for continuing efforts. The new patch structure looks better to
me (although the boundary between patches 0001 and 0002 is somewhat
fuzzy, e.g. the function NameListToString is used already in the first
On Thu, Mar 30, 2023 at 4:06 AM Pavel Stehule
wrote:
> Hi
>
> ne 26. 3. 2023 v 19:44 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
>> > On Fri, Mar 24, 2023 at 08:04:08AM +0100, Pavel Stehule wrote:
>> > čt 23. 3. 2023 v 19:54 odesílatel Pavel Stehule <
>> pavel.steh...@gmail.com>
>
>
>> example
>>
>> create variable a as int;
>> create table foo(a int);
>>
>> select a from foo; -- the "a" is ambiguous, variable "a" is shadowed
>>
>> This is a basic case, and the unique names don't help. The variables are
>> more aggressive in namespace than tables, because they don't
On Wed, Apr 5, 2023 at 1:58 PM Pavel Stehule
wrote:
>
>
> st 5. 4. 2023 v 19:20 odesílatel Greg Stark napsal:
>
>> On Sun, 26 Mar 2023 at 07:34, Julien Rouhaud wrote:
>> >
>> > This feature can significantly increase log size, so it's disabled by
>> default.
>> > For testing or development
On Thu, Apr 6, 2023 at 1:58 AM Pavel Stehule wrote:
>
> st 5. 4. 2023 v 19:20 odesílatel Greg Stark napsal:
>>
>> On Sun, 26 Mar 2023 at 07:34, Julien Rouhaud wrote:
>> >
>> > This feature can significantly increase log size, so it's disabled by
>> > default.
>> > For testing or development
st 5. 4. 2023 v 19:20 odesílatel Greg Stark napsal:
> On Sun, 26 Mar 2023 at 07:34, Julien Rouhaud wrote:
> >
> > This feature can significantly increase log size, so it's disabled by
> default.
> > For testing or development environments it's recommended to enable it if
> you
> > use session
On Sun, 26 Mar 2023 at 07:34, Julien Rouhaud wrote:
>
> This feature can significantly increase log size, so it's disabled by default.
> For testing or development environments it's recommended to enable it if you
> use session variables.
I think it's generally not practical to have warnings for
> On Tue, Mar 28, 2023 at 09:34:20PM +0200, Pavel Stehule wrote:
> Hi
>
> > Talking about documentation I've noticed that the implementation
> > contains few limitations, that are not mentioned in the docs. Examples
> > are WITH queries:
> >
> > WITH x AS (LET public.svar = 100) SELECT * FROM
On 30.03.23 10:49, Pavel Stehule wrote:
If I reorganize the patch to the following structure, can be it useful
for you?
1. really basic functionality (no temporary variables, no def
expressions, no memory cleaning)
SELECT variable
LET should be supported + doc, + related tests.
2.
Hi
st 29. 3. 2023 v 12:17 odesílatel Peter Eisentraut <
peter.eisentr...@enterprisedb.com> napsal:
> On 24.03.23 08:04, Pavel Stehule wrote:
> > Maybe I can divide the patch 0002-session-variables to three sections -
> > related to memory management, planning and execution?
>
> Personally, I
Hi
ne 26. 3. 2023 v 19:44 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Fri, Mar 24, 2023 at 08:04:08AM +0100, Pavel Stehule wrote:
> > čt 23. 3. 2023 v 19:54 odesílatel Pavel Stehule >
> > napsal:
> >
> > > čt 23. 3. 2023 v 16:33 odesílatel Peter Eisentraut <
> > >
On 24.03.23 08:04, Pavel Stehule wrote:
Maybe I can divide the patch 0002-session-variables to three sections -
related to memory management, planning and execution?
Personally, I find the existing split not helpful. There is no value
(to me) in putting code, documentation, and tests in
Hi
ne 26. 3. 2023 v 19:53 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Sun, Mar 26, 2023 at 07:32:05PM +0800, Julien Rouhaud wrote:
> > Hi,
> >
> > I just have a few minor wording improvements for the various comments /
> > documentation you quoted.
>
> Talking about
ne 26. 3. 2023 v 13:32 odesílatel Julien Rouhaud
napsal:
> Hi,
>
> I just have a few minor wording improvements for the various comments /
> documentation you quoted.
>
> On Sun, Mar 26, 2023 at 08:53:49AM +0200, Pavel Stehule wrote:
> > út 21. 3. 2023 v 17:18 odesílatel Peter Eisentraut <
> >
> On Sun, Mar 26, 2023 at 07:32:05PM +0800, Julien Rouhaud wrote:
> Hi,
>
> I just have a few minor wording improvements for the various comments /
> documentation you quoted.
Talking about documentation I've noticed that the implementation
contains few limitations, that are not mentioned in the
> On Fri, Mar 24, 2023 at 08:04:08AM +0100, Pavel Stehule wrote:
> čt 23. 3. 2023 v 19:54 odesílatel Pavel Stehule
> napsal:
>
> > čt 23. 3. 2023 v 16:33 odesílatel Peter Eisentraut <
> > peter.eisentr...@enterprisedb.com> napsal:
> >
> >> The other issue is that by its nature this patch adds a
Hi,
I just have a few minor wording improvements for the various comments /
documentation you quoted.
On Sun, Mar 26, 2023 at 08:53:49AM +0200, Pavel Stehule wrote:
> út 21. 3. 2023 v 17:18 odesílatel Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> napsal:
>
> > - What is the purpose of
čt 23. 3. 2023 v 19:54 odesílatel Pavel Stehule
napsal:
> Hi
>
>
> čt 23. 3. 2023 v 16:33 odesílatel Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> napsal:
>
>> On 17.03.23 21:50, Pavel Stehule wrote:
>> > Hi
>> >
>> > rebase + fix-update pg_dump tests
>> >
>> > Regards
>> >
>> > Pavel
Hi
čt 23. 3. 2023 v 16:33 odesílatel Peter Eisentraut <
peter.eisentr...@enterprisedb.com> napsal:
> On 17.03.23 21:50, Pavel Stehule wrote:
> > Hi
> >
> > rebase + fix-update pg_dump tests
> >
> > Regards
> >
> > Pavel
> >
>
> I have spent several hours studying the code and the past
On 17.03.23 21:50, Pavel Stehule wrote:
Hi
rebase + fix-update pg_dump tests
Regards
Pavel
I have spent several hours studying the code and the past discussions.
The problem I see in general is that everyone who reviews and tests the
patches finds more problems, behavioral, weird
On 17.03.23 21:50, Pavel Stehule wrote:
rebase + fix-update pg_dump tests
I have a few comments on the code:
0001
ExecGrant_Variable() could probably use ExecGrant_common().
The additions to syscache.c should be formatted to the new style.
in pg_variable.h:
- create_lsn ought to have a
st 8. 3. 2023 v 16:35 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, Mar 08, 2023 at 08:31:07AM +0100, Pavel Stehule wrote:
> > pá 3. 3. 2023 v 21:19 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> > napsal:
> >
> > > > On Tue, Feb 28, 2023 at 06:12:50AM +0100, Pavel
> On Wed, Mar 08, 2023 at 08:31:07AM +0100, Pavel Stehule wrote:
> pá 3. 3. 2023 v 21:19 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
> > > On Tue, Feb 28, 2023 at 06:12:50AM +0100, Pavel Stehule wrote:
> > >
> > > fresh rebase
> >
> > I'm continuing to review, this time going
> On Tue, Feb 28, 2023 at 06:12:50AM +0100, Pavel Stehule wrote:
>
> fresh rebase
I'm continuing to review, this time going through shadowing stuff in
transformColumnRef, IdentifyVariable etc. Well, that's a lot of leg work
for rather little outcome :) I guess all attempts to simplify this part
Hi
I read notes from the FOSDEM developer meeting, and I would like to repeat
notice about motivation for introduction of session variables, and one
reason why session_variables are not transactional, and why they should not
be replaced by temp tables is performance.
There are more use cases
>
> > I can be wrong, but from these numbers I don't think so these sync cycles
> > should to contain CHECK_FOR_INTERRUPTS
> >
> > What do you think?
>
> Well, there is always possibility someone will create more variables
> than any arbitrary limit we have tested for. But I see your point and
>
> On Mon, Jan 23, 2023 at 07:09:27PM +0100, Pavel Stehule wrote:
> po 23. 1. 2023 v 15:25 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
> > > On Sun, Jan 22, 2023 at 07:47:07PM +0100, Pavel Stehule wrote:
> > > pá 20. 1. 2023 v 21:35 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
po 23. 1. 2023 v 15:25 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Sun, Jan 22, 2023 at 07:47:07PM +0100, Pavel Stehule wrote:
> > pá 20. 1. 2023 v 21:35 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> > napsal:
> >
> > > * I think it was already mentioned in the thread,
> On Sun, Jan 22, 2023 at 07:47:07PM +0100, Pavel Stehule wrote:
> pá 20. 1. 2023 v 21:35 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
> > * I think it was already mentioned in the thread, there seems to be not a
> > single usage of CHECK_FOR_INTERRUPTS in session_variable.c .
I've accumulated another collection of various questions and comments. As a
side note I'm getting a good feeling about this patch, those part I've read so
far looks good to me.
* I've suddenly realized one could use pseudo types for variables, and
it not always works. E.g.:
=# create
On Tue, Jan 10, 2023 at 08:35:16PM +0100, Pavel Stehule wrote:
> út 10. 1. 2023 v 3:20 odesílatel Julien Rouhaud napsal:
> >
> > Another new behavior I see is the new rowtype_only parameter for
> > LookupVariable. Has this been discussed?
> >
>
> I think so it was discussed about table shadowing
Hi,
On Sat, Jan 07, 2023 at 08:09:27AM +0100, Pavel Stehule wrote:
> >
> > Hmm, how safe is it for third-party code to access the stored data directly
> > rather than a copy? If it makes extension fragile if they're not careful
> > enough with cache invalidation, or even give them a way to mess
Hi,
On Fri, Jan 06, 2023 at 08:02:41PM +0100, Pavel Stehule wrote:
> pá 6. 1. 2023 v 5:11 odesílatel Julien Rouhaud napsal:
>
> >
> > +Datum
> > +GetSessionVariableWithTypeCheck(Oid varid, bool *isNull, Oid
> > expected_typid)
> > +{
> > + SVariable svar;
> > +
> > + svar =
Hi,
On Fri, Dec 23, 2022 at 08:38:43AM +0100, Pavel Stehule wrote:
>
> I am sending an updated patch, fixing the mentioned issue. Big thanks for
> testing, and checking.
There were multiple reviews in the last weeks which reported some issues, but
unless I'm missing something I don't see any
> On Thu, Dec 22, 2022 at 08:45:57PM +0100, Pavel Stehule wrote:
> > From the first look it seems some major topics the discussion is evolving
> > are about:
> >
> > * Validity of the use case. Seems to be quite convincingly addressed in
> > [1] and
> > [2].
> >
> > * Complicated logic around
čt 22. 12. 2022 v 17:15 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> Hi,
>
> I'm continuing review the patch slowly, and have one more issue plus one
> philosophical question.
>
> The issue have something to do with variables invalidation. Enabling
> debug_discard_caches = 1 (about
Hi,
I'm continuing review the patch slowly, and have one more issue plus one
philosophical question.
The issue have something to do with variables invalidation. Enabling
debug_discard_caches = 1 (about which I've learned from this thread) and
running this subset of the test suite:
Op 14-12-2022 om 05:54 schreef Pavel Stehule:
Hi
fresh rebase
typo alert:
v20221214-0003-LET-command.patch contains
errmsg("target session varible is of type %s"
('varible' should be 'variable')
Erik
po 14. 11. 2022 v 8:00 odesílatel Sergey Shinderuk <
s.shinde...@postgrespro.ru> napsal:
> On 13.11.2022 20:59, Pavel Stehule wrote:
> > fresh rebase
>
> Hello,
>
> Sorry, I haven't been following this thread, but I'd like to report a
> memory management bug. I couldn't apply the latest patches,
On 13.11.2022 20:59, Pavel Stehule wrote:
fresh rebase
Hello,
Sorry, I haven't been following this thread, but I'd like to report a
memory management bug. I couldn't apply the latest patches, so I tested
with v20221104-1-* patches applied atop of commit b0284bfb1db.
postgres=# create
pá 4. 11. 2022 v 15:28 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Fri, Nov 04, 2022 at 03:17:18PM +0100, Pavel Stehule wrote:
> > > I've stumbled upon something that looks weird to me (inspired by the
> > > example from tests):
> > >
> > > =# create variable v2 as int;
>
Hi,
On Sat, Nov 05, 2022 at 05:04:31PM +0100, Tomas Vondra wrote:
>
> I did a quick initial review of this patch series - attached is a
> version with "review" commits for some of the parts. The current patch
> seems in pretty good shape, most of what I noticed are minor issues. I
> plan to do a
> On Fri, Nov 04, 2022 at 03:17:18PM +0100, Pavel Stehule wrote:
> > I've stumbled upon something that looks weird to me (inspired by the
> > example from tests):
> >
> > =# create variable v2 as int;
> > =# let v2 = 3;
> > =# create view vv2 as select coalesce(v2, 0) + 1000 as result
Hi
pá 4. 11. 2022 v 15:08 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Fri, Nov 04, 2022 at 05:58:06AM +0100, Pavel Stehule wrote:
> > Hi
> >
> > fix clang warning
>
> I've stumbled upon something that looks weird to me (inspired by the
> example from tests):
>
> =#
Hi,
On Fri, Nov 04, 2022 at 03:07:48PM +0100, Dmitry Dolgov wrote:
> > On Fri, Nov 04, 2022 at 05:58:06AM +0100, Pavel Stehule wrote:
> > Hi
> >
> > fix clang warning
>
> I've stumbled upon something that looks weird to me (inspired by the
> example from tests):
>
> =# create variable v2 as
> On Fri, Nov 04, 2022 at 05:58:06AM +0100, Pavel Stehule wrote:
> Hi
>
> fix clang warning
I've stumbled upon something that looks weird to me (inspired by the
example from tests):
=# create variable v2 as int;
=# let v2 = 3;
=# create view vv2 as select coalesce(v2, 0) + 1000 as
Hi
ne 30. 10. 2022 v 19:05 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Thu, Oct 13, 2022 at 07:41:32AM +0200, Pavel Stehule wrote:
> > rebased with simplified code related to usage of pfree function
>
> Thanks for the patch, great work!
>
> I've got a couple of questions,
> On Thu, Oct 13, 2022 at 07:41:32AM +0200, Pavel Stehule wrote:
> rebased with simplified code related to usage of pfree function
Thanks for the patch, great work!
I've got a couple of questions, although I haven't fully finished reviewing yet
(so more to come):
* I'm curious about ALTER
Hi,
On Thu, Oct 13, 2022 at 07:41:32AM +0200, Pavel Stehule wrote:
>
> > I fixed the commit message of 0001 patch. Fixed shadowed variables too.
Thanks!
> >
> > There is a partially open issue, where I and Julien are not sure about a
> > solution, and we would like to ask for the community's
Hi,
On Tue, Sep 06, 2022 at 06:23:12PM +0800, Julien Rouhaud wrote:
> On Tue, Sep 06, 2022 at 08:43:59AM +0200, Pavel Stehule wrote:
> > Hi
> >
> > After talking with Julian I removed "debug" fields name and nsname from
> > SVariable structure. When it is possible it is better to read these
On Sat, Sep 03, 2022 at 11:00:51PM +0800, Julien Rouhaud wrote:
> Hi,
>
> On Fri, Sep 02, 2022 at 07:42:00AM +0200, Pavel Stehule wrote:
> >
> > rebased today
>
> After some off-list discussion with Pavel, I'm sending some proposal patches
> (in .txt extension) to apply to the last patchset.
>
>
Hi,
On Fri, Sep 02, 2022 at 07:42:00AM +0200, Pavel Stehule wrote:
>
> rebased today
After some off-list discussion with Pavel, I'm sending some proposal patches
(in .txt extension) to apply to the last patchset.
To sum up, when a session issues a DROP VARIABLE, the session will receive an
st 24. 8. 2022 v 10:04 odesílatel Erik Rijkers napsal:
> Op 24-08-2022 om 08:37 schreef Pavel Stehule:
> >>
> >
> > I fixed these.
> >
>
> > [v20220824-1-*.patch]
>
> Hi Pavel,
>
> I noticed just now that variable assignment (i.e., LET) unexpectedly
> (for me anyway) cast the type of the input
Hi,
On Sat, Aug 27, 2022 at 01:17:45PM +0200, Pavel Stehule wrote:
>
> after some thinking I think that instead of sequence I can use LSN. The
> combination oid, LSN should be unique forever
Yeah I was about suggesting doing that instead of a sequence, so +1 for that
approach!
I've been
st 24. 8. 2022 v 10:04 odesílatel Erik Rijkers napsal:
> Op 24-08-2022 om 08:37 schreef Pavel Stehule:
> >>
> >
> > I fixed these.
> >
>
> > [v20220824-1-*.patch]
>
> Hi Pavel,
>
> I noticed just now that variable assignment (i.e., LET) unexpectedly
> (for me anyway) cast the type of the input
Op 24-08-2022 om 08:37 schreef Pavel Stehule:
I fixed these.
> [v20220824-1-*.patch]
Hi Pavel,
I noticed just now that variable assignment (i.e., LET) unexpectedly
(for me anyway) cast the type of the input value. Surely that's wrong?
The documentation says clearly enough:
'The
út 23. 8. 2022 v 14:57 odesílatel Julien Rouhaud
napsal:
> On Tue, Aug 23, 2022 at 11:27:45AM +0200, Pavel Stehule wrote:
> > út 23. 8. 2022 v 7:56 odesílatel Julien Rouhaud
> napsal:
> >
> > >
> > > I've been thinking a bit more about the shadowing, and one scenario we
> > > didn't
> > >
On Tue, Aug 23, 2022 at 11:27:45AM +0200, Pavel Stehule wrote:
> út 23. 8. 2022 v 7:56 odesílatel Julien Rouhaud napsal:
>
> >
> > I've been thinking a bit more about the shadowing, and one scenario we
> > didn't
> > discuss is something like this naive example:
> >
> > CREATE TABLE tt(a text, b
1 - 100 of 217 matches
Mail list logo
