> 6. Oracle
>
> Oracle PL/SQL allows the use of package variables. PL/SQL is +/- ADA
> language - and package variables are "global" variables. They are not
> directly visible from SQL, but Oracle allows reduced syntax for functions
> without arguments, so you need to write a wrapper
>
> CREATE OR
Hi
> You can see, the RDBMS allows different types of session variables,
> different implementations. Usually one system allows more implementation of
> session variables. There is a possibility of emulation implementation
> between RDBMS, but security setting is possible only in Oracle or DB2.
>
ne 2. 6. 2024 v 23:31 odesílatel Peter Eisentraut
napsal:
>
> On 25.05.24 12:50, Pavel Stehule wrote:
> > It looks odd - It is not intuitive, it introduces new inconsistency
> > inside Postgres, or with solutions in other databases. No other database
> > has a similar rule, so users coming from Or
On 25.05.24 12:50, Pavel Stehule wrote:
It looks odd - It is not intuitive, it introduces new inconsistency
inside Postgres, or with solutions in other databases. No other database
has a similar rule, so users coming from Oracle, Db2, or MSSQL, Firebird
will be confused. Users that use PL/pgSQL
pá 31. 5. 2024 v 15:49 odesílatel Wolfgang Walther
napsal:
> Pavel Stehule:
> > When you write RAISE NOTICE '%', x, then PLpgSQL parser rewrite it to
> > RAISE NOTICE '%', SELECT $1
> >
> > There is no parser just for expressions.
>
> That's why my suggestion in [1] already made a difference betw
Pavel Stehule:
When you write RAISE NOTICE '%', x, then PLpgSQL parser rewrite it to
RAISE NOTICE '%', SELECT $1
There is no parser just for expressions.
That's why my suggestion in [1] already made a difference between:
SELECT var;
and
SELECT col, var FROM table, var;
So the "only requir
>
>
>
>
>> In this case you could still write:
>>
>> RAISE NOTICE '% %', x, (SELECT a,b FROM y);
>>
>> (assuming only x is a variable here)
>>
>
no - y was a composite variable.
When you write RAISE NOTICE '%', x, then PLpgSQL parser rewrite it to RAISE
NOTICE '%', SELECT $1
There is no parser ju
pá 31. 5. 2024 v 15:29 odesílatel Wolfgang Walther
napsal:
> Pavel Stehule:
> > The session variables can be used in queries, but should be used in
> > PL/pgSQL expressions, and then the mandatory usage in FROM clause will
> > do lot of problems and unreadable code like
> >
> > DO $$
> > BEGIN
>
Pavel Stehule:
The session variables can be used in queries, but should be used in
PL/pgSQL expressions, and then the mandatory usage in FROM clause will
do lot of problems and unreadable code like
DO $$
BEGIN
RAISE NOTICE '% %', (SELECT x FROM x), (SELECT a,b FROM y);
END
$$
This require
pá 31. 5. 2024 v 15:02 odesílatel Pavel Stehule
napsal:
>
>
> pá 31. 5. 2024 v 13:37 odesílatel Wolfgang Walther <
> walt...@technowledgy.de> napsal:
>
>> Pavel Stehule:
>> > But in this case you could make variables and tables share the same
>> > namespace, i.e. forbid creating a variabl
pá 31. 5. 2024 v 13:37 odesílatel Wolfgang Walther
napsal:
> Pavel Stehule:
> > But in this case you could make variables and tables share the same
> > namespace, i.e. forbid creating a variable with the same name as an
> > already existing table.
> >
> >
> > It helps, but not on 100%
Pavel Stehule:
But in this case you could make variables and tables share the same
namespace, i.e. forbid creating a variable with the same name as an
already existing table.
It helps, but not on 100% - there is a search path
I think we can ignore the search_path for this discussi
pá 31. 5. 2024 v 13:10 odesílatel Wolfgang Walther
napsal:
> Pavel Stehule:
> > 2. But my main argument is, it is not really safe - it solves Peter's
> > use case, but if I use a reverse example of Peter's case, I still have a
> > problem.
> >
> > I can have a variable x, and then I can write que
Pavel Stehule:
2. But my main argument is, it is not really safe - it solves Peter's
use case, but if I use a reverse example of Peter's case, I still have a
problem.
I can have a variable x, and then I can write query like `SELECT x FROM x`;
but if somebody creates table x(x int), then the q
pá 31. 5. 2024 v 11:46 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Tue, May 28, 2024 at 05:18:02PM GMT, Pavel Stehule wrote:
> >
> > I propose another variants. First we can introduce pseudo function VAR(
> ).
> > The argument should be session variables. The name of this funct
> On Tue, May 28, 2024 at 05:18:02PM GMT, Pavel Stehule wrote:
>
> I propose another variants. First we can introduce pseudo function VAR( ).
> The argument should be session variables. The name of this function can be
> pgvar, globvar, ... We can talk about good name, it should not be too long,
>
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 pg_va
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 a
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 pg_variab
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 que
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 variable
>
>
>
>
>>
>> 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 c
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, a
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, a
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 at
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 s
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 unqua
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 pote
> 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 th
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 anyo
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 fi
ú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 pick
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 af
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 loo
> 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 to
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 "ba
> 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
> concentra
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 th
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 ready
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 can
> 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 i
>>
>> 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
>> NamesFromLi
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 *NamesFro
> 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, than
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 possib
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 correctl
> 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
o
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 requir
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 envi
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 env
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 va
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 x
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. su
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 fin
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 <
> > > peter.eisen
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 thre
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 documentat
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 <
> > pe
> 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 d
> 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 lo
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 s
č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 discussion
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 internal
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 "va
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 Stehu
> 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 throu
> 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
we
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 wher
>
> > 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
> do
> 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, the
> 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 . But
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 variab
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 u
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 = prep
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 foll
> 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 inval
č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 w
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:
CREATE
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, s
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 vari
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 m
1 - 100 of 233 matches
Mail list logo
