On Wed, May 21, 2025 at 07:49:34AM +0200, Pavel Stehule wrote:
> st 21. 5. 2025 v 2:21 odesílatel Michael Paquier napsal:
> One thing that I keep hearing about this feature is that this would be
> really helpful for migration from Oracle to PostgreSQL, helping a lot
> with rewrites of
On Wed, May 21, 2025 at 09:12:54AM +0200, Pavel Stehule wrote:
> Last discussion is related to reducing the size of the session variable patch
> set.
>
> I have an idea to use variable's fencing more aggressively from the start, and
> then we can reduce it in future. This should not break issues w
On Wed, May 21, 2025 at 07:15:27AM +0200, Pavel Stehule wrote:
> út 20. 5. 2025 v 23:07 odesílatel Bruce Momjian napsal:
> > If no committer intends to pick it up and commit it, I think the proper
> > action would be to step up and reject the patch set, not complain about
> the
> >
On Tue, 2025-05-20 at 17:06 -0400, Bruce Momjian wrote:
> f no committer intends to pick it up and commit it, I think the proper
> > action would be to step up and reject the patch set, not complain about the
> > insistence of the author.
>
> Are you saying I should not complain until we have offi
Hi
út 19. 11. 2024 v 20:14 odesílatel Pavel Stehule
napsal:
> Hi
>
> I wrote POC of VARIABLE(varname) syntax support
>
> here is a copy from regress test
>
> SET session_variables_ambiguity_warning TO on;
> SET session_variables_use_fence_warning_guard TO on;
> SET search_path TO 'public';
> CRE
st 21. 5. 2025 v 8:27 odesílatel Laurenz Albe
napsal:
> On Tue, 2025-05-20 at 17:06 -0400, Bruce Momjian wrote:
> > f no committer intends to pick it up and commit it, I think the proper
> > > action would be to step up and reject the patch set, not complain
> about the
> > > insistence of the au
st 21. 5. 2025 v 2:21 odesílatel Michael Paquier
napsal:
> On Tue, May 20, 2025 at 10:28:31PM +0200, Pavel Stehule wrote:
> > This topic is difficult, because there is no common solution. SQL/PSM is
> > almost dead. T-SQL (and MySQL) design is weak and cannot be used for
> > security.
> > Oracle'
út 20. 5. 2025 v 23:07 odesílatel Bruce Momjian napsal:
> On Tue, May 20, 2025 at 10:36:54PM +0200, Laurenz Albe wrote:
> > On Tue, 2025-05-20 at 16:28 -0400, Bruce Momjian wrote:
> > > Well, we do have a right, e.g., we would not allow someone to
> repeatedly
> > > post patches for a Postgres ex
On Tue, May 20, 2025 at 10:28:31PM +0200, Pavel Stehule wrote:
> This topic is difficult, because there is no common solution. SQL/PSM is
> almost dead. T-SQL (and MySQL) design is weak and cannot be used for
> security.
> Oracle's design is joined with just one environment. And although almost
> a
On Tue, May 20, 2025 at 10:28:31PM +0200, Pavel Stehule wrote:
> út 20. 5. 2025 v 18:39 odesílatel Bruce Momjian napsal:
> I sent a reduced version a few months ago - from 21 patches to 8 (and it can
> be
> reduced to six if we postpone tools for detection ambiguity).
> The timing was not perfect
On Tue, May 20, 2025 at 10:36:54PM +0200, Laurenz Albe wrote:
> On Tue, 2025-05-20 at 16:28 -0400, Bruce Momjian wrote:
> > Well, we do have a right, e.g., we would not allow someone to repeatedly
> > post patches for a Postgres extension we don't manage, or the jdbc
> > driver. I also don't think
Hi
út 20. 5. 2025 v 18:39 odesílatel Bruce Momjian napsal:
> On Tue, May 20, 2025 at 01:33:18PM -0300, Marcos Pegoraro wrote:
> > Em ter., 20 de mai. de 2025 às 11:56, Bruce Momjian
> > escreveu:
> >
> > I will again ask why this patch set is being reposted when there is
> no
> > plan t
On Tue, 2025-05-20 at 16:28 -0400, Bruce Momjian wrote:
> On Tue, May 20, 2025 at 08:47:36PM +0200, Daniel Gustafsson wrote:
> > > On 20 May 2025, at 18:39, Bruce Momjian wrote:
> > > My only point is that we should only be using email lists for work that
> > > is being actively worked on to be ad
On Tue, May 20, 2025 at 08:47:36PM +0200, Daniel Gustafsson wrote:
> > On 20 May 2025, at 18:39, Bruce Momjian wrote:
> > My only point is that we should only be using email lists for work that
> > is being actively worked on to be added to community Postgres. There
> > has been talk of a trimmed
> On 20 May 2025, at 18:39, Bruce Momjian wrote:
>
> On Tue, May 20, 2025 at 01:33:18PM -0300, Marcos Pegoraro wrote:
>> Em ter., 20 de mai. de 2025 às 11:56, Bruce Momjian
>> escreveu:
>>
>>I will again ask why this patch set is being reposted when there is no
>>plan to apply it to git
On Tue, May 20, 2025 at 01:33:18PM -0300, Marcos Pegoraro wrote:
> Em ter., 20 de mai. de 2025 às 11:56, Bruce Momjian
> escreveu:
>
> I will again ask why this patch set is being reposted when there is no
> plan to apply it to git master
>
> Too bad. I would love to have this functional
Em ter., 20 de mai. de 2025 às 11:56, Bruce Momjian
escreveu:
> I will again ask why this patch set is being reposted when there is no
> plan to apply it to git master
Too bad. I would love to have this functionality, from the user's point of
view there are problems where it would solve them wo
On Thu, May 15, 2025 at 08:48:37AM +0200, Pavel Stehule wrote:
> Hi
>
> fresh rebase
I will again ask why this patch set is being reposted when there is no
plan to apply it to git master?
--
Bruce Momjian https://momjian.us
EDB https://enterpris
Hi
po 17. 3. 2025 v 21:53 odesílatel Marcos Pegoraro
napsal:
> Em seg., 17 de mar. de 2025 às 15:33, Pavel Stehule <
> pavel.steh...@gmail.com> escreveu:
>
>> I was asked for sending a reduced patchset
>>
>
> Would be good to explain what this reduced patchset is.
> Complete patch contains this
Em seg., 17 de mar. de 2025 às 15:33, Pavel Stehule
escreveu:
> I was asked for sending a reduced patchset
>
Would be good to explain what this reduced patchset is.
Complete patch contains this and that
Reduced patch contains only this.
Regards
Marcos
On Fri, Feb 7, 2025 at 3:25 PM Pavel Stehule wrote:
>
Hi
The following review is based on v20250117.
pg_dump order seems not right.
CREATE FUNCTION public.test11(text) RETURNS text
LANGUAGE sql
AS $$select v4 $$;
CREATE VARIABLE public.v4 AS text;
first dump function then variable. rest
hi.
git diff --check
shows there is some white space there.
Adding hack mailing list discussion links in each patch would be great.
Others said that the first 6 patches are essential, maybe we can only
post the first 6 patches.
so the test CI result would be more reliable. also people would not
f
On Mon, 2025-01-20 at 15:15 -0500, Bruce Momjian wrote:
> Yes, I think we passed the Desirability criteria with the feedback on
> this thread, but it is now a question of whether the code complexity
> justifies the feature. I saw a few people saying they want _some_ parts
> of the patch, which ope
On Fri, Jan 17, 2025 at 03:47:28PM +0100, Álvaro Herrera wrote:
> On 2025-Jan-17, Bruce Momjian wrote:
>
> > Is this really something we are considering applying, since it has been
> > around for years? I am unclear on that and we had better know if we are
> > going to continue reviewing this.
>
Hi
po 20. 1. 2025 v 8:56 odesílatel Álvaro Herrera
napsal:
> On 2025-Jan-17, Bruce Momjian wrote:
>
> > Is this really something we are considering applying, since it has been
> > around for years? I am unclear on that and we had better know if we are
> > going to continue reviewing this.
>
> T
On 2025-Jan-17, Bruce Momjian wrote:
> Is this really something we are considering applying, since it has been
> around for years? I am unclear on that and we had better know if we are
> going to continue reviewing this.
The fact that the patch has been around for years doesn't automatically
mea
Le 17/01/2025 à 19:01, Bruce Momjian a écrit :
On Fri, Jan 17, 2025 at 04:55:07PM +0100, Pavel Stehule wrote:
pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian napsal:
So this feature would be like global GUC variables, with permission
control?
+ types and domain type check - holds da
Em sex., 17 de jan. de 2025 às 13:01, Bruce Momjian
escreveu:
> Okay, good summary. Now, can people give feedback that they would want
> this committed to PostgreSQL?
I would love to have this functionality as soon as possible.
I already mentioned to Pavel that he did something very big, and
c
>
> > pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian
> napsal:
>
> Okay, good summary. Now, can people give feedback that they would want
> this committed to PostgreSQL?
>
I would love to have this functionality as soon as possible.
I already mentioned to Pavel that he did something very big, a
Bruce Momjian:
Now, can people give feedback that they would want
this committed to PostgreSQL?
From a user's perspective: Yes!
I've been waiting for this for a long time and I really hope this can go
through, eventually.
Best,
Wolfgang
> On Fri, Jan 17, 2025 at 11:01:41AM GMT, Bruce Momjian wrote:
> On Fri, Jan 17, 2025 at 04:55:07PM +0100, Pavel Stehule wrote:
> > pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian napsal:
> >
> > So this feature would be like global GUC variables, with permission
> > control?
> >
> > + typ
On Fri, 2025-01-17 at 11:01 -0500, Bruce Momjian wrote:
> On Fri, Jan 17, 2025 at 04:55:07PM +0100, Pavel Stehule wrote:
> > pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian napsal:
> >
> > So this feature would be like global GUC variables, with permission
> > control?
> >
> > + types an
On Fri, Jan 17, 2025 at 11:01:41AM -0500, Bruce Momjian wrote:
> On Fri, Jan 17, 2025 at 04:55:07PM +0100, Pavel Stehule wrote:
> > pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian napsal:
> >
> > So this feature would be like global GUC variables, with permission
> > control?
> >
> > + t
On Fri, Jan 17, 2025 at 04:55:07PM +0100, Pavel Stehule wrote:
> pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian napsal:
>
> So this feature would be like global GUC variables, with permission
> control?
>
> + types and domain type check - holds data in binary form - there are not
> conv
pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian napsal:
> On Fri, Jan 17, 2025 at 04:32:07PM +0100, Pavel Stehule wrote:
> > This discussion was around 2017 when I wrote a proposal and I hadn't a
> feeling
>
> 2017 is seven years ago so it would be good to get current feedback on
> the desirabili
On Fri, Jan 17, 2025 at 04:32:07PM +0100, Pavel Stehule wrote:
> This discussion was around 2017 when I wrote a proposal and I hadn't a feeling
2017 is seven years ago so it would be good to get current feedback on
the desirability of this feature.
> There is one stronger argument for session var
Hi
pá 17. 1. 2025 v 15:39 odesílatel Bruce Momjian napsal:
> On Fri, Jan 17, 2025 at 03:28:55PM +0100, Pavel Stehule wrote:
> > Dne pá 17. 1. 2025 15:16 uživatel Bruce Momjian
> napsal:
> > Is this really something we are considering applying, since it has
> been
> > around for years?
On Fri, Jan 17, 2025 at 02:48:29PM +0100, Pavel Stehule wrote:
> Hi
>
> pá 17. 1. 2025 v 14:41 odesílatel Bruce Momjian napsal:
>
> On Fri, Jan 17, 2025 at 08:18:20AM +0100, Pavel Stehule wrote:
> > Hi
> >
> > fix oid collision
>
> What is the purpose of continually posting
Hi
pá 17. 1. 2025 v 14:41 odesílatel Bruce Momjian napsal:
> On Fri, Jan 17, 2025 at 08:18:20AM +0100, Pavel Stehule wrote:
> > Hi
> >
> > fix oid collision
>
> What is the purpose of continually posting this patch to the email
> lists?
>
The people still do a review, so I am fixing this patch.
On Fri, Jan 17, 2025 at 08:18:20AM +0100, Pavel Stehule wrote:
> Hi
>
> fix oid collision
What is the purpose of continually posting this patch to the email
lists?
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let ur
hi.
you forgot change
acldefault
should add
'V' for SESSION VARIABLE
in doc/src/sgml/ddl.sgml
maybe some examples () of session variables being
shadowed would be great.
because doc/src/sgml/ref/create_variable.sgml said
Session variables can be shadowed by other identifiers.
For
hi.
some minor issues.
'transformMergeStmt also needs
"qry->hasSessionVariables = pstate->p_hasSessionVariables;"
?
acldefault in doc/src/sgml/func.sgml
Need an update for SESSION VARIABLE?
Table 9.70. Access Privilege Inquiry Functions
sorting order: has_session_variable_privilege should after
ne 5. 1. 2025 v 17:11 odesílatel jian he
napsal:
> + /*
> + * The arguments of EXECUTE are evaluated by a direct expression
> + * executor call. This mode doesn't support session variables yet.
> + * It will be enabled later.
> + */
> + if (pstate->p_hasSessionVariables)
> + elog(ERROR, "session
Hi
ne 5. 1. 2025 v 5:52 odesílatel jian he
napsal:
> diff --git a/src/include/nodes/primnodes.h b/src/include/nodes/primnodes.h
> index 9c2957eb546..624858db301 100644
> --- a/src/include/nodes/primnodes.h
> +++ b/src/include/nodes/primnodes.h
> @@ -361,6 +361,9 @@ typedef struct Const
> * of
comment out the changes in
src/backend/utils/cache/plancache.c
// /* process session variables */
// if (OidIsValid(parsetree->resultVariable))
// {
// if (acquire)
// LockDatabaseObject(VariableRelationId, parsetree->resultVariable,
//
+ /*
+ * The arguments of EXECUTE are evaluated by a direct expression
+ * executor call. This mode doesn't support session variables yet.
+ * It will be enabled later.
+ */
+ if (pstate->p_hasSessionVariables)
+ elog(ERROR, "session variable cannot be used as an argument");
it should be:
/*
diff --git a/src/include/nodes/primnodes.h b/src/include/nodes/primnodes.h
index 9c2957eb546..624858db301 100644
--- a/src/include/nodes/primnodes.h
+++ b/src/include/nodes/primnodes.h
@@ -361,6 +361,9 @@ typedef struct Const
* of the `paramid' field contain the SubLink's subLinkId, and
* the l
hi.
in the function svariableStartupReceiver all these "ereport(ERROR"
cannot happen,
since transformLetStmt already did all the heavy work.
base on https://www.postgresql.org/docs/current/error-message-reporting.html
all these "ereport(ERROR," in the svariableStartupReceiver can be
simplified as
Hi
>> + {
>> + /* the last field of list can be star too */
>> + Assert(IsA(field2, A_Star));
>> +
>> + /*
>> + * In this case, the field1 should be variable name. But
>> + * direct unboxing of composite session variables is not
>> + * supported now, and then we don't need to try lookup
>> + * re
On Sun, Dec 29, 2024 at 5:50 AM Pavel Stehule wrote:
>
> Hi
>
>
>> --<<>>>---
>> + else
>> + {
>> + /* the last field of list can be star too */
>> + Assert(IsA(field2, A_Star));
>> +
>> + /*
>> + * In this case, the field1 should be variable name. But
>> + * direct unb
Hi
so 28. 12. 2024 v 11:35 odesílatel jian he
napsal:
> hi.
>
> src9=# select 'XLogRecPtr'::regtype;
> ERROR: type "xlogrecptr" does not exist
> LINE 1: select 'XLogRecPtr'::regtype;
>^
> so
> + varcreate_lsn XLogRecPtr
> should be
> varcreate_lsn pg_lsn
> ?
>
done
>
> also
>
hi.
+ if (stmt->collClause)
+ collation = LookupCollation(pstate,
+ stmt->collClause->collname,
+ stmt->collClause->location);
+ else
+ collation = typcollation;;
two semi-colon. should be only one.
--<<>>>---
+ /* locks the variable with an AccessShareLock */
+ varid
Hi
pá 27. 12. 2024 v 16:20 odesílatel jian he
napsal:
> hi.
>
> + if (!OidIsValid(varid))
> + AcceptInvalidationMessages();
> + else if (OidIsValid(varid))
> + LockDatabaseObject(VariableRelationId, varid, 0, AccessShareLock);
>
> we can change it to
> + if (!OidIsValid(varid))
> + AcceptInvalid
hi.
src9=# select 'XLogRecPtr'::regtype;
ERROR: type "xlogrecptr" does not exist
LINE 1: select 'XLogRecPtr'::regtype;
^
so
+ varcreate_lsn XLogRecPtr
should be
varcreate_lsn pg_lsn
?
also
+
+
+ varcreate_lsn XLogRecPtr
+
+
+ LSN of the transacti
hi.
+ if (!OidIsValid(varid))
+ AcceptInvalidationMessages();
+ else if (OidIsValid(varid))
+ LockDatabaseObject(VariableRelationId, varid, 0, AccessShareLock);
we can change it to
+ if (!OidIsValid(varid))
+ AcceptInvalidationMessages();
+ else
+ LockDatabaseObject(VariableRelationId, varid, 0,
hi.
review is based on
v20241219-0002-Storage-for-session-variables-and-SQL-interface.patch
and
v20241219-0001-Enhancing-catalog-for-support-session-variables-and-.patch.
in doc/src/sgml/catalogs.sgml
defaclobjtype char
Type of object this entry is for:
r = relation (table, view),
S = sequenc
hi.
/*
* has_session_variable_privilege variants
*These are all named "has_session_variable_privilege" at the SQL level.
*They take various combinations of variable name, variable OID,
*user name, user OID, or implicit user = current_user.
*
*The result is a b
hi.
GRANT|REVOKE ALL VARIABLES IN SCHEMA schema_name [, ...] }
seems to work.
might be better to add tests.
also src/bin/psql/tab-complete.in.c
COMPLETE_WITH_SCHEMA_QUERY_PLUS(Query_for_list_of_grantables,
we can also add "ALL VARIABLES IN SCHEMA "
also need change this in grant.sgml:
Th
Hi
st 20. 11. 2024 v 21:14 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Tue, Nov 19, 2024 at 08:14:01PM +0100, Pavel Stehule wrote:
> > Hi
> >
> > I wrote POC of VARIABLE(varname) syntax support
>
> Thanks, the results look good. I'm still opposed the idea of having a
> warning
On Mon, Dec 9, 2024 at 2:33 AM Pavel Stehule wrote:
>
> Hi
>
again. only applied
v20241208-0001-Enhancing-catalog-for-support-session-variables-and-.patch.
/* we want SessionVariableCreatePostprocess to see the catalog changes. */
0001 doesn't have SessionVariableCreatePostprocess,
so this commen
On Thu, Dec 5, 2024 at 2:52 PM Pavel Stehule wrote:
>
> Hi
>
> only rebase
hi.
disclaimer, i *only* applied
v20241205-0001-Enhancing-catalog-for-support-session-variables-and-.patch.
create variable v2 as text;
alter variable v2 rename to v2;
ERROR: session variable "v2" already exists in schem
st 20. 11. 2024 v 21:14 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Tue, Nov 19, 2024 at 08:14:01PM +0100, Pavel Stehule wrote:
> > Hi
> >
> > I wrote POC of VARIABLE(varname) syntax support
>
> Thanks, the results look good. I'm still opposed the idea of having a
> warning, an
> On Tue, Nov 19, 2024 at 08:14:01PM +0100, Pavel Stehule wrote:
> Hi
>
> I wrote POC of VARIABLE(varname) syntax support
Thanks, the results look good. I'm still opposed the idea of having a
warning, and think it has to be an error -- but it's my subjective
opinion. Lets see if there are more vot
Em ter., 19 de nov. de 2024 às 16:15, Pavel Stehule
escreveu:
> I wrote POC of VARIABLE(varname) syntax support
>
Not related with POC of VARIABLE but seeing your patches ...
Wouldn't it be better to use just one syntax and message for what to do ON
COMMIT ?
When creating a new variable you us
st 20. 11. 2024 v 15:15 odesílatel Marcos Pegoraro
napsal:
> Em qua., 20 de nov. de 2024 às 10:52, Pavel Stehule <
> pavel.steh...@gmail.com> escreveu:
>
>> COMMIT can be a little bit messy. TRANSACTION END is more intuitive, I
>> think.
>>
>>>
> Exactly to be not messy I would just ON COMMIT for
Em qua., 20 de nov. de 2024 às 10:52, Pavel Stehule
escreveu:
> COMMIT can be a little bit messy. TRANSACTION END is more intuitive, I
> think.
>
>>
Exactly to be not messy I would just ON COMMIT for all, and DOCs can
explain that this option is ignored for temp objects and do the same at the
end
Hi
st 20. 11. 2024 v 14:29 odesílatel Marcos Pegoraro
napsal:
> Em ter., 19 de nov. de 2024 às 16:15, Pavel Stehule <
> pavel.steh...@gmail.com> escreveu:
>
>> I wrote POC of VARIABLE(varname) syntax support
>>
>
> Not related with POC of VARIABLE but seeing your patches ...
>
> Wouldn't it be b
so 16. 11. 2024 v 15:56 odesílatel Wolfgang Walther
napsal:
> Dmitry Dolgov:
> > This sounds to me like an argument against allowing name clashing between
> > variables and tables. It makes even more sense, since session variables
> are in
> > many ways similar to tables.
>
> +1
>
It doesn't hel
so 16. 11. 2024 v 23:07 odesílatel Pavel Stehule
napsal:
>
>
> so 16. 11. 2024 v 18:13 odesílatel Wolfgang Walther <
> walt...@technowledgy.de> napsal:
>
>> Pavel Stehule:
>> > (global (temp)) table can hold 0, 1 or more rows (and rows are always
>> > composite of 0..n fields). The variable holds
so 16. 11. 2024 v 23:49 odesílatel Pavel Stehule
napsal:
>
>
> so 16. 11. 2024 v 15:27 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
>> > On Sat, Nov 16, 2024 at 07:10:31AM GMT, Pavel Stehule wrote:
>>
>> Sorry, got distracted. Let me try to answer step by step.
>>
>> > > As far as
so 16. 11. 2024 v 15:27 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Sat, Nov 16, 2024 at 07:10:31AM GMT, Pavel Stehule wrote:
>
> Sorry, got distracted. Let me try to answer step by step.
>
> > > As far as I recall, last time this topic was discussed in hackers, two
> > > optio
so 16. 11. 2024 v 18:13 odesílatel Wolfgang Walther
napsal:
> Pavel Stehule:
> > (global (temp)) table can hold 0, 1 or more rows (and rows are always
> > composite of 0..n fields). The variable holds a value of some type.
> > Proposed session variables are like plpgsql variables (only with
> > d
Pavel Stehule:
(global (temp)) table can hold 0, 1 or more rows (and rows are always
composite of 0..n fields). The variable holds a value of some type.
Proposed session variables are like plpgsql variables (only with
different scope). In Postgres there is a difference between a scalar
variabl
Hi
> As a side note, I've recently caught myself thinking "it would be cool to
> have
> session variables here". The use case was preparing a policy for RLS,
> based on
> some session-level data set by an application. This session-level data is
> of a
> composite data type, so simple current_sett
Dmitry Dolgov:
This sounds to me like an argument against allowing name clashing between
variables and tables. It makes even more sense, since session variables are in
many ways similar to tables.
+1
My mental model of a session variable is similar to a single-row,
optionally global temporary
> On Sat, Nov 16, 2024 at 07:10:31AM GMT, Pavel Stehule wrote:
Sorry, got distracted. Let me try to answer step by step.
> > As far as I recall, last time this topic was discussed in hackers, two
> > options were proposed: the one with VARIABLE(name), what you mention
> > here; and another one wi
st 13. 11. 2024 v 17:35 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Sun, Nov 10, 2024 at 06:51:40PM GMT, Pavel Stehule wrote:
> > ne 10. 11. 2024 v 17:19 odesílatel Pavel Stehule <
> pavel.steh...@gmail.com>
> > napsal:
> > I thought a lot of time about better solutions for ide
čt 14. 11. 2024 v 8:41 odesílatel Pavel Stehule
napsal:
>
>
> st 13. 11. 2024 v 17:35 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
>> > On Sun, Nov 10, 2024 at 06:51:40PM GMT, Pavel Stehule wrote:
>> > ne 10. 11. 2024 v 17:19 odesílatel Pavel Stehule <
>> pavel.steh...@gmail.com>
st 13. 11. 2024 v 17:35 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Sun, Nov 10, 2024 at 06:51:40PM GMT, Pavel Stehule wrote:
> > ne 10. 11. 2024 v 17:19 odesílatel Pavel Stehule <
> pavel.steh...@gmail.com>
> > napsal:
> > I thought a lot of time about better solutions for ide
st 13. 11. 2024 v 17:35 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Sun, Nov 10, 2024 at 06:51:40PM GMT, Pavel Stehule wrote:
> > ne 10. 11. 2024 v 17:19 odesílatel Pavel Stehule <
> pavel.steh...@gmail.com>
> > napsal:
> > I thought a lot of time about better solutions for ide
> On Sun, Nov 10, 2024 at 06:51:40PM GMT, Pavel Stehule wrote:
> ne 10. 11. 2024 v 17:19 odesílatel Pavel Stehule
> napsal:
> I thought a lot of time about better solutions for identifier collisions
> and I really don't think so there is some consistent user friendly syntax.
> Personally I think t
st 13. 11. 2024 v 15:24 odesílatel Laurenz Albe
napsal:
> Thanks for the updated patch set.
>
> Here is my review of patch 0005:
>
> > --- a/src/backend/access/transam/xact.c
> > +++ b/src/backend/access/transam/xact.c
> > +#include "commands/session_variable.h"
>
> You probably forgot to move th
ne 10. 11. 2024 v 18:51 odesílatel Pavel Stehule
napsal:
>
>
> ne 10. 11. 2024 v 17:19 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> ne 10. 11. 2024 v 16:24 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
>> napsal:
>>
>>> Hi folks,
>>>
>>> Thanks for continuing this work. As a side note, I wou
ne 10. 11. 2024 v 18:41 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Sun, Nov 10, 2024 at 05:19:09PM GMT, Pavel Stehule wrote:
> > ne 10. 11. 2024 v 16:24 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> > napsal:
> >
> > > Hi folks,
> > >
> > > Thanks for continuing this work
ne 10. 11. 2024 v 17:19 odesílatel Pavel Stehule
napsal:
>
>
> ne 10. 11. 2024 v 16:24 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
>> Hi folks,
>>
>> Thanks for continuing this work. As a side note, I would like to mention
>> how strange the situation in this CF item is. If I und
> On Sun, Nov 10, 2024 at 05:19:09PM GMT, Pavel Stehule wrote:
> ne 10. 11. 2024 v 16:24 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
> > Hi folks,
> >
> > Thanks for continuing this work. As a side note, I would like to mention
> > how strange the situation in this CF item is. If I
ne 10. 11. 2024 v 16:24 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> Hi folks,
>
> Thanks for continuing this work. As a side note, I would like to mention
> how strange the situation in this CF item is. If I understand correctly,
> there are two hackers threads discussing the same p
Hi folks,
Thanks for continuing this work. As a side note, I would like to mention
how strange the situation in this CF item is. If I understand correctly,
there are two hackers threads discussing the same patch, with recent
patches posted in both of them. This is obviously confusing, e.g. the
mai
On Sat, 2024-11-02 at 08:36 +0100, Pavel Stehule wrote:
> so 2. 11. 2024 v 6:46 odesílatel Laurenz Albe
> napsal:
> > - The commit message is headed "memory cleaning after DROP VARIABLE", but
> > the rest of the commit message speaks of sinval messages. These two
> > things are independent,
so 2. 11. 2024 v 6:46 odesílatel Laurenz Albe
napsal:
> On Tue, 2024-10-29 at 08:16 +0100, Pavel Stehule wrote:
> > again, necessary rebase
>
> I have started looking at patch 5, and I have some questions and comments.
>
> - The commit message is headed "memory cleaning after DROP VARIABLE", but
On Tue, 2024-10-29 at 08:16 +0100, Pavel Stehule wrote:
> again, necessary rebase
I have started looking at patch 5, and I have some questions and comments.
- The commit message is headed "memory cleaning after DROP VARIABLE", but
the rest of the commit message speaks of sinval messages. These
On Fri, 2024-10-25 at 07:21 +0200, Pavel Stehule wrote:
> > > + elog(DEBUG1, "pg_session_variables start");
> >
> > I don't think that message is necessary, particularly with DEBUG1.
> > I have removed this message and the "end" message as well.
>
> removed
Thanks.
> > > +
st 23. 10. 2024 v 6:11 odesílatel Laurenz Albe
napsal:
> I have gone over patch 3 from the set and worked on the comments.
>
> Apart from that, I have modified your patch as follows:
>
> > +/*
> > + * pg_session_variables - designed for testing
> > + *
> > + * This is a function designed for test
... and here is a review for patch 4
I didn't change any code, just added the odd article to a comment.
While running the regression tests with "make installcheck", I noticed two
problems:
--- /home/laurenz/postgresql/src/test/regress/expected/session_variables.out
2024-10-24 11:14:06.717
I have gone over patch 3 from the set and worked on the comments.
Apart from that, I have modified your patch as follows:
> +/*
> + * pg_session_variables - designed for testing
> + *
> + * This is a function designed for testing and debugging. It returns the
> + * content of sessionvars as-is,
On Thu, 2024-08-29 at 19:33 +0200, Pavel Stehule wrote:
> > > > > > + /*
> > > > > > + * Although svar is freshly validated in this point, the
> > > > > svar->is_valid can
> > > > > > + * be false, due possible accepting invalidation message
> > > > > inside domain
> > > > > > +
Hi
út 27. 8. 2024 v 16:52 odesílatel Laurenz Albe
napsal:
> time""On Tue, 2024-08-27 at 08:52 +0200, Pavel Stehule wrote:
> > I can throw 200KB from another 300KB patch set which can be better for
> review, but it
> > can be harder to maintain this patch set. I'll try it, and I'll send a
> reduc
time""On Tue, 2024-08-27 at 08:52 +0200, Pavel Stehule wrote:
> I can throw 200KB from another 300KB patch set which can be better for
> review, but it
> can be harder to maintain this patch set. I'll try it, and I'll send a
> reduced version.
That was not a criticism, and I think the way you sp
Hi
út 27. 8. 2024 v 8:15 odesílatel Laurenz Albe
napsal:
> On Thu, 2024-08-15 at 07:55 +0200, Pavel Stehule wrote:
> > út 30. 7. 2024 v 21:46 odesílatel Laurenz Albe
> napsal:
> > > - A general reminder: single line comments should start with a lower
> case
> > > letter and have to period in
On Thu, 2024-08-15 at 07:55 +0200, Pavel Stehule wrote:
> út 30. 7. 2024 v 21:46 odesílatel Laurenz Albe
> napsal:
> > - A general reminder: single line comments should start with a lower case
> > letter and have to period in the end:
>
> Should it be "have not to period in the end" ?
I made
1 - 100 of 273 matches
Mail list logo
