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
čt 1. 8. 2024 v 13:22 odesílatel Laurenz Albe
napsal:
> On Thu, 2024-08-01 at 08:12 +0200, Pavel Stehule wrote:
> > fresh rebase + fix format in doc
>
> Thanks!
>
> I'm curious, but too lazy to build the patch now, so I'm asking:
> what did you do about this error?
>
I try to investigate this is
On Thu, 2024-08-01 at 08:12 +0200, Pavel Stehule wrote:
> fresh rebase + fix format in doc
Thanks!
I'm curious, but too lazy to build the patch now, so I'm asking:
what did you do about this error?
> CREATE VARIABLE var AS date;
> LET var = current_date;
> PREPARE stmt(date) AS SELECT $1;
> EXEC
čt 1. 8. 2024 v 9:45 odesílatel Erik Rijkers napsal:
> doc-build fails: a slash tumbled backwards in doc/src/sgml:
>
> $ grep 'xref.*.\\>' *.sgml
> plpgsql.sgml: (see ).
>
> That should simply be a forward slash, of course.
>
should be fixed in my today patchset
>
> Thanks,
>
> Erik Rijk
doc-build fails: a slash tumbled backwards in doc/src/sgml:
$ grep 'xref.*.\\>' *.sgml
plpgsql.sgml: (see ).
That should simply be a forward slash, of course.
Thanks,
Erik Rijkers
Op 8/1/24 om 08:12 schreef Pavel Stehule:
Hi
fresh rebase + fix format in doc
Regards
Pavel
st 31. 7. 2024 v 8:57 odesílatel Laurenz Albe
napsal:
> On Wed, 2024-07-31 at 08:41 +0200, Pavel Stehule wrote:
> > Probably you didn't attach new files - the second patch is not complete.
> Or you didn't make changes there?
>
> Hm. What is missing?
>
let.sgml,
session_variable.c
svariable_rece
On Wed, 2024-07-31 at 08:41 +0200, Pavel Stehule wrote:
> Probably you didn't attach new files - the second patch is not complete. Or
> you didn't make changes there?
Hm. What is missing?
Yours,
Laurenz Albe
út 30. 7. 2024 v 21:46 odesílatel Laurenz Albe
napsal:
> This is my review of the second patch in the series.
>
> Again, I mostly changed code comments and documentation.
>
> Noteworthy remarks:
>
> - A general reminder: single line comments should start with a lower case
> letter and have to p
Thanks for the updated patch set.
I found a problem in 0019-transactional-variables.patch:
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -9851,6 +9851,17 @@ SCRAM-SHA-256$:&l
+
+ varistransact
+ boolean
+
+
+
út 23. 7. 2024 v 23:41 odesílatel Laurenz Albe
napsal:
> On Tue, 2024-07-23 at 16:34 +0200, Laurenz Albe wrote:
> > CREATE VARIABLE command:
> >
> > This is buggy:
> >
> > CREATE VARIABLE str AS text NOT NULL DEFAULT NULL;
> >
> > Ugh.
> >
> > SELECT str;
> > ERROR: null value is
On Wed, 2024-07-24 at 17:19 +0200, Pavel Stehule wrote:
> > This is buggy:
> >
> > CREATE VARIABLE str AS text NOT NULL DEFAULT NULL;
> >
> > Ugh.
> >
> > SELECT str;
> > ERROR: null value is not allowed for NOT NULL session variable
> > "laurenz.str"
> > DETAIL: The resul
On Tue, 2024-07-23 at 16:34 +0200, Laurenz Albe wrote:
> CREATE VARIABLE command:
>
> This is buggy:
>
> CREATE VARIABLE str AS text NOT NULL DEFAULT NULL;
>
> Ugh.
>
> SELECT str;
> ERROR: null value is not allowed for NOT NULL session variable
> "laurenz.str"
> DETAIL:
Thanks for the fixes and the new patch set!
I think that this would be a very valuable feature!
This is a very incomplete review after playing with the patch set for a while.
Some bugs and oddities I have found:
"psql" support:
\? gives
\dV [PATTERN] list variables
I think th
po 22. 7. 2024 v 10:23 odesílatel Laurenz Albe
napsal:
> Thanks for the updated patch and the fixes!
>
> On Mon, 2024-07-22 at 08:37 +0200, Pavel Stehule wrote:
> > > > --- a/doc/src/sgml/ref/pg_restore.sgml
> > > > +++ b/doc/src/sgml/ref/pg_restore.sgml
> > >
> > > > +
> > > > + -A cl
Thanks for the updated patch and the fixes!
On Mon, 2024-07-22 at 08:37 +0200, Pavel Stehule wrote:
> > > --- a/doc/src/sgml/ref/pg_restore.sgml
> > > +++ b/doc/src/sgml/ref/pg_restore.sgml
> >
> > > +
> > > + -A > > class="parameter">schema_variable
> > > + --variable= > > class=
On Sat, 2021-04-10 at 08:58 +0200, Pavel Stehule wrote:
> I am sending a strongly updated patch for schema variables.
>
> I rewrote an execution of a LET statement. In the previous implementation I
> hacked
> STMT_SELECT. Now, I introduced a new statement STMT_LET, and I implemented a
> new
> ex
Hi
I am sending a strongly updated patch for schema variables.
I rewrote an execution of a LET statement. In the previous implementation I
hacked STMT_SELECT. Now, I introduced a new statement STMT_LET, and I
implemented a new executor node SetVariable. Now I think this
implementation is much cle
Hi
so 13. 3. 2021 v 7:01 odesílatel Pavel Stehule
napsal:
> Hi
>
> fresh rebase
>
only rebase
Regards
Pavel
>
> Pavel
>
schema-variables-20210404.patch.gz
Description: application/gzip
Hi
po 22. 3. 2021 v 10:47 odesílatel Pavel Stehule
napsal:
> Hi
>
> st 17. 3. 2021 v 13:05 odesílatel Erik Rijkers napsal:
>
>>
>> > On 2021.03.13. 07:01 Pavel Stehule wrote:
>> > Hi
>> > fresh rebase
>> > [schema-variables-20210313.patch.gz]
>>
>>
>> Hi Pavel,
>>
>> I notice that the phrase
Hi
st 17. 3. 2021 v 13:05 odesílatel Erik Rijkers napsal:
>
> > On 2021.03.13. 07:01 Pavel Stehule wrote:
> > Hi
> > fresh rebase
> > [schema-variables-20210313.patch.gz]
>
>
> Hi Pavel,
>
> I notice that the phrase 'schema variable' is not in the index at the end
> ('bookindex.html'). Not goo
> On 2021.03.13. 07:01 Pavel Stehule wrote:
> Hi
> fresh rebase
> [schema-variables-20210313.patch.gz]
Hi Pavel,
I notice that the phrase 'schema variable' is not in the index at the end
('bookindex.html'). Not good.
It is also not in the index at the front of the manual - also not good.
Hi
fresh rebase
Pavel
schema-variables-20210313.patch.gz
Description: application/gzip
út 16. 2. 2021 v 18:46 odesílatel Pavel Stehule
napsal:
> Hi
>
> út 2. 2. 2021 v 9:43 odesílatel Pavel Stehule
> napsal:
>
>> Hi
>>
>> rebase and set PK for pg_variable table
>>
>
> rebase
>
rebase
> Pavel
>
>
>> Regards
>>
>> Pavel
>>
>
schema-variables-20200301.patch.gz
Description: appl
Hi
út 2. 2. 2021 v 9:43 odesílatel Pavel Stehule
napsal:
> Hi
>
> rebase and set PK for pg_variable table
>
rebase
Pavel
> Regards
>
> Pavel
>
schema-variables-20200216.patch.gz
Description: application/gzip
Hi
rebase and set PK for pg_variable table
Regards
Pavel
schema-variables-20210202.patch.gz
Description: application/gzip
Hi
only rebase
Regards
Pavel
schema-variables-20200123.patch.gz
Description: application/gzip
po 18. 1. 2021 v 15:24 odesílatel Erik Rijkers napsal:
> On 2021-01-18 10:59, Pavel Stehule wrote:
> >>
> > and here is the patch
> > [schema-variables-20200118.patch.gz ]
>
>
> One small thing:
>
> The drop variable synopsis is:
>
> DROP VARIABLE [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]
1 - 100 of 166 matches
Mail list logo
