On Fri, May 16, 2025 at 3:26 PM Richard Guo wrote:
>
> On Fri, May 16, 2025 at 1:00 PM Alexander Lakhin wrote:
> > I've discovered yet another way to trigger that error:
> > create table vt (a int, b int generated always as (a * 2), c int);
> > insert into vt values(1);
> > alter table vt alter c
On Fri, May 16, 2025 at 1:00 PM Alexander Lakhin wrote:
> I've discovered yet another way to trigger that error:
> create table vt (a int, b int generated always as (a * 2), c int);
> insert into vt values(1);
> alter table vt alter column c type bigint using b + c;
>
> ERROR: XX000: unexpected v
Hello Richard,
22.02.2025 16:55, Richard Guo wrote:
create table t (a int, b int);
create table vt (a int, b int generated always as (a * 2));
insert into t values (1, 1);
insert into vt values (1);
# select 1 from t t1 where exists
(select 1 from vt where exists
(select t1.a from t t
On Mon, Feb 24, 2025 at 9:07 PM Dean Rasheed wrote:
> On Mon, 24 Feb 2025 at 09:21, Richard Guo wrote:
> > Here are the updated patches with revised comments and some tweaks to
> > the commit messages. I plan to push them in one or two days.
> LGTM.
Pushed. Thanks all for working on this issu
On Mon, 24 Feb 2025 at 09:21, Richard Guo wrote:
>
> Here are the updated patches with revised comments and some tweaks to
> the commit messages. I plan to push them in one or two days.
>
LGTM.
Regards,
Dean
On Mon, Feb 24, 2025 at 3:50 PM jian he wrote:
> On Sat, Feb 22, 2025 at 11:12 PM Richard Guo wrote:
> > On Sat, Feb 22, 2025 at 11:55 PM Richard Guo wrote:
> > > Attached are the updated patches to fix all the mentioned issues. I
> > > plan to push them early next week after staring at the cod
On Sat, Feb 22, 2025 at 11:12 PM Richard Guo wrote:
>
> On Sat, Feb 22, 2025 at 11:55 PM Richard Guo wrote:
> > Attached are the updated patches to fix all the mentioned issues. I
> > plan to push them early next week after staring at the code for a bit
> > longer, barring any objections.
>
> Si
On Sat, Feb 22, 2025 at 11:55 PM Richard Guo wrote:
> Attached are the updated patches to fix all the mentioned issues. I
> plan to push them early next week after staring at the code for a bit
> longer, barring any objections.
Sign... I neglected to make the change in 0001 that a Var newnode
co
On Sat, Feb 22, 2025 at 2:35 AM Dean Rasheed wrote:
> On Fri, 21 Feb 2025 at 06:16, Richard Guo wrote:
> > * The expansion of virtual generated columns occurs after subquery
> > pullup, which can lead to issues. This was an oversight on my part.
> > Initially, I believed it wasn't possible for a
On Fri, 21 Feb 2025 at 06:16, Richard Guo wrote:
>
> Yeah, it's annoying that the two replace_rte_variables callbacks have
> so much code duplication. I think it's a win to make them share
> common code. What do you think about making this refactor a separate
> patch, as it doesn't seem directly
On Thu, Feb 20, 2025 at 12:25 AM Dean Rasheed wrote:
> On Wed, 19 Feb 2025 at 01:42, Dean Rasheed wrote:
> > One thing I don't like about this is that it's introducing more code
> > duplication between pullup_replace_vars() and
> > ReplaceVarsFromTargetList(). Those already had a lot of code in c
On Wed, Feb 19, 2025 at 11:25 PM Dean Rasheed wrote:
>
> One of the new regression tests fails, which actually appears to be a
> pre-existing grouping sets bug, due to the fact that only non-Vars are
> wrapped in PHVs. This bug can be triggered without virtual generated
> columns:
>
> CREATE TABLE
On Wed, Feb 19, 2025 at 11:25 PM Dean Rasheed wrote:
>
> On Wed, 19 Feb 2025 at 01:42, Dean Rasheed wrote:
> >
> > One thing I don't like about this is that it's introducing more code
> > duplication between pullup_replace_vars() and
> > ReplaceVarsFromTargetList(). Those already had a lot of cod
On Wed, 19 Feb 2025 at 01:42, Dean Rasheed wrote:
>
> One thing I don't like about this is that it's introducing more code
> duplication between pullup_replace_vars() and
> ReplaceVarsFromTargetList(). Those already had a lot of code in common
> before RETURNING OLD/NEW was added, and this is dupl
On Tue, 18 Feb 2025 at 13:12, Richard Guo wrote:
>
> > It seems to me that, for a relation in the rangetable that has virtual
> > generated columns, we can consider it a subquery to some extent. For
> > instance, suppose we have a query:
> >
> > select ... from ... join t on ...;
> >
> > and supp
On Tue, Feb 18, 2025 at 7:09 PM Richard Guo wrote:
> It seems to me that, for a relation in the rangetable that has virtual
> generated columns, we can consider it a subquery to some extent. For
> instance, suppose we have a query:
>
> select ... from ... join t on ...;
>
> and suppose t.b is a v
On Sat, Feb 15, 2025 at 9:37 PM Dean Rasheed wrote:
> On Fri, 14 Feb 2025 at 10:59, Peter Eisentraut wrote:
> > Maybe a short-term fix would be to error out if we find ourselves about
> > to expand a Var with varnullingrels != NULL. That would mean you
> > couldn't use a virtual generated column
On Sat, Feb 15, 2025 at 8:37 PM Dean Rasheed wrote:
>
> On Fri, 14 Feb 2025 at 10:59, Peter Eisentraut wrote:
> >
> > On 13.02.25 14:06, jian he wrote:
> > > I didn't solve the out join semantic issue.
> > > i am wondering, can we do the virtual generated column expansion in
> > > the rewrite sta
On Fri, 14 Feb 2025 at 10:59, Peter Eisentraut wrote:
>
> On 13.02.25 14:06, jian he wrote:
> > I didn't solve the out join semantic issue.
> > i am wondering, can we do the virtual generated column expansion in
> > the rewrite stage as is,
> > and wrap the expressions in PHVs if the virtual gener
On 13.02.25 14:06, jian he wrote:
I didn't solve the out join semantic issue.
i am wondering, can we do the virtual generated column expansion in
the rewrite stage as is,
and wrap the expressions in PHVs if the virtual generated
columns come from the nullable side of an outer join.
PlaceHolderV
On Tue, Feb 11, 2025 at 10:34 AM Richard Guo wrote:
>
> On Mon, Feb 10, 2025 at 1:16 PM Zhang Mingli wrote:
> > I believe virtual columns should behave like stored columns, except they
> > don't actually use storage.
> > Virtual columns are computed when the table is read, and they should adhere
On Tue, Feb 11, 2025 at 10:34 AM Richard Guo wrote:
> Yeah, I also feel that the virtual generated columns should adhere to
> outer join semantics, rather than being unconditionally replaced by
> the generation expressions. But maybe I'm wrong.
>
> If that's the case, this incorrect-result issue
On Mon, Feb 10, 2025 at 1:16 PM Zhang Mingli wrote:
> I believe virtual columns should behave like stored columns, except they
> don't actually use storage.
> Virtual columns are computed when the table is read, and they should adhere
> to the same rules of join semantics.
> I agree with Richard
On Feb 10, 2025 at 12:53 +0800, jian he , wrote:
>
> please check attached.
>
> > BTW, I was curious about what happens if the replacement expression is
> > constant, so I tried running the query below.
> >
> > CREATE TABLE t (a int, b int GENERATED ALWAYS AS (1 + 1));
> > INSERT INTO t VALUES (1);
On Mon, Feb 10, 2025 at 11:54 AM Richard Guo wrote:
>
> On Sun, Feb 9, 2025 at 7:02 PM Zhang Mingli wrote:
> > On Feb 9, 2025 at 16:00 +0800, Alexander Lakhin ,
> > wrote:
> > Please look at a planner error with a virtual generated column triggered
> > by the following script:
> > CREATE TABLE t
On Sun, Feb 9, 2025 at 7:02 PM Zhang Mingli wrote:
> On Feb 9, 2025 at 16:00 +0800, Alexander Lakhin , wrote:
> Please look at a planner error with a virtual generated column triggered
> by the following script:
> CREATE TABLE t(a int, b int GENERATED ALWAYS AS (a * 1));
>
> SELECT SUM(CASE WHEN t
On Feb 9, 2025 at 16:00 +0800, Alexander Lakhin , wrote:
>
> Please look at a planner error with a virtual generated column triggered
> by the following script:
> CREATE TABLE t(a int, b int GENERATED ALWAYS AS (a * 1));
>
> SELECT SUM(CASE WHEN t.b = 1 THEN 1 ELSE 1 END) OVER (PARTITION BY t.a)
>
Hello Peter,
07.02.2025 14:34, Peter Eisentraut wrote:
I've committed it. Thanks.
Please look at a planner error with a virtual generated column triggered
by the following script:
CREATE TABLE t(a int, b int GENERATED ALWAYS AS (a * 1));
SELECT SUM(CASE WHEN t.b = 1 THEN 1 ELSE 1 END) OVER (
On 06.02.25 14:03, vignesh C wrote:
One suggestion: for the option where the user specifies
publish_generated_columns as virtual (as shown below), could we change
the error indicating that virtual generated columns are not currently
supported?
CREATE PUBLICATION pub1 FOR TABLE t1 WITH (publish_ge
On 06.02.25 00:25, Dean Rasheed wrote:
On Tue, 4 Feb 2025 at 22:36, Peter Eisentraut wrote:
Yeah, this is quite contorted. I have renamed it like you suggested.
I looked over this again and I think the patch is in good shape to be committed.
I've committed it. Thanks.
One thought that
On Wed, 5 Feb 2025 at 04:06, Peter Eisentraut wrote:
>
> On 27.01.25 13:42, Dean Rasheed wrote:
> > On Mon, 27 Jan 2025 at 09:59, Peter Eisentraut wrote:
> >>
> >> Here is an updated patch that integrates the above changes and also
> >> makes some adjustments now that the logical replication conf
On Tue, 4 Feb 2025 at 22:36, Peter Eisentraut wrote:
>
> Yeah, this is quite contorted. I have renamed it like you suggested.
I looked over this again and I think the patch is in good shape to be committed.
One thought that occurred to me was whether it would be better for the
psql describe out
On 28.01.25 10:40, Shlok Kyal wrote:
Test 5: Update publication on non virtual gen with no column list specified
CREATE TABLE t1 (a int, b int GENERATED ALWAYS AS (a * 2) VIRTUAL);
create publication pub1 for table t1;
alter table t1 replica identity full;
update t1 set a = 10;
No error is thro
On Mon, 27 Jan 2025 at 15:29, Peter Eisentraut wrote:
>
> On 15.01.25 20:37, Peter Eisentraut wrote:
> > On 15.01.25 15:12, Dean Rasheed wrote:
> >> On Tue, 14 Jan 2025 at 13:37, Peter Eisentraut
> >> wrote:
> >>>
> >>> Here is a new patch with that fixed and also a few
> >>> tweaks suggested by
On Mon, 27 Jan 2025 at 09:59, Peter Eisentraut wrote:
>
> Here is an updated patch that integrates the above changes and also
> makes some adjustments now that the logical replication configuration
> questions are resolved. I think this is complete now.
>
In struct ResultRelInfo, the following f
On Tue, 14 Jan 2025 at 19:08, Peter Eisentraut wrote:
>
> On 13.01.25 19:15, Dean Rasheed wrote:
> > On Wed, 8 Jan 2025 at 16:14, Peter Eisentraut wrote:
> >>
> >> Here is a new patch version
> >
> > In expand_generated_columns_in_expr():
> >
> > + RangeTblEntry *rte;
> > +
> > + rte
On Thu, 16 Jan 2025 at 01:16, Peter Eisentraut wrote:
>
> On 15.01.25 08:11, vignesh C wrote:
> > On Tue, 14 Jan 2025 at 19:08, Peter Eisentraut wrote:
> >>
> >>
> >> I've also added a patch that addresses logical replication. It
> >> basically adds back some of the prohibitions against includin
On 15.01.25 08:11, vignesh C wrote:
On Tue, 14 Jan 2025 at 19:08, Peter Eisentraut wrote:
I've also added a patch that addresses logical replication. It
basically adds back some of the prohibitions against including generated
columns in publications that have been lifted, but this time only
On 15.01.25 15:12, Dean Rasheed wrote:
On Tue, 14 Jan 2025 at 13:37, Peter Eisentraut wrote:
Here is a new patch with that fixed and also a few
tweaks suggested by Jian.
I'm hoping to push my RETURNING OLD/NEW patch [1] soon, so I thought
that I would check how it works together with this p
On Tue, 14 Jan 2025 at 13:37, Peter Eisentraut wrote:
>
> Here is a new patch with that fixed and also a few
> tweaks suggested by Jian.
>
I'm hoping to push my RETURNING OLD/NEW patch [1] soon, so I thought
that I would check how it works together with this patch. The good
news is that AFAICS ev
On Tue, 14 Jan 2025 at 19:08, Peter Eisentraut wrote:
>
>
> I've also added a patch that addresses logical replication. It
> basically adds back some of the prohibitions against including generated
> columns in publications that have been lifted, but this time only for
> virtual generated columns
On 09.01.25 13:41, jian he wrote:
we can not ALTER COLUMN DROP EXPRESSION for virtual for now.
so the following comments in generated_virtual.sql conflict with the output.
```
-- check that dependencies between columns have also been removed
ALTER TABLE gtest29 DROP COLUMN a; -- should not drop
On 09.01.25 09:38, jian he wrote:
create user foo;
create user bar;
grant create on schema public to foo;
\c - foo
create table t1 (id int, ccnum text, ccredacted text generated always as
(repeat('*', 12) || substr(ccnum, 13, 4)) virtual);
grant select (id, ccredacted) on table t1 to bar;
insert
On Wed, 8 Jan 2025 at 16:14, Peter Eisentraut wrote:
>
> Here is a new patch version
In expand_generated_columns_in_expr():
+ RangeTblEntry *rte;
+
+ rte = makeNode(RangeTblEntry);
+ rte->relid = RelationGetRelid(rel);
+
+ node = expand_generated_columns_internal(node, re
On Wed, 8 Jan 2025 at 16:14, Peter Eisentraut wrote:
>
> One thing I could use some review on is the access control handling and
> security in general. You can create virtual generated columns that have
> their own access privileges but which can read columns that the user
> does not have access
On Thu, Jan 9, 2025 at 3:28 AM Peter Eisentraut wrote:
>
> On 08.01.25 17:38, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> On 03.12.24 15:15, jian he wrote:
> >>> SELECT attrelid, attname, attgenerated FROM pg_attribute WHERE
> >>> attgenerated IN ('v') and (attnotnull or not atthasdef);
> >
On Thu, Jan 9, 2025 at 12:14 AM Peter Eisentraut wrote:
>
> Here is a new patch version where I have gathered various pieces of
> feedback and improvement suggestions that are scattered over this
> thread. I hope I got them all. I will respond to the respective
> messages directly to give my res
Em qua., 8 de jan. de 2025 às 16:23, Vik Fearing
escreveu:
> This is lying to the planner, and you get to enjoy whatever breaks
> because of it. A function that accesses external data is not immutable;
> it is stable at best.
>
I understand that, but it's not documented, so users can think that
On 08.01.25 17:38, Tom Lane wrote:
Peter Eisentraut writes:
On 03.12.24 15:15, jian he wrote:
SELECT attrelid, attname, attgenerated FROM pg_attribute WHERE
attgenerated IN ('v') and (attnotnull or not atthasdef);
I don't understand what the purpose of testing attnotnull is. That is
indepe
On 08/01/2025 20:19, Marcos Pegoraro wrote:
Em qua., 8 de jan. de 2025 às 13:14, Peter Eisentraut
escreveu:
Here is a new patch version where I have gathered various pieces of
feedback and improvement suggestions that are scattered over this
thread. I hope I got them all. I wil
Em qua., 8 de jan. de 2025 às 13:14, Peter Eisentraut
escreveu:
> Here is a new patch version where I have gathered various pieces of
> feedback and improvement suggestions that are scattered over this
> thread. I hope I got them all. I will respond to the respective
> messages directly to give
Peter Eisentraut writes:
> On 03.12.24 15:15, jian he wrote:
>> SELECT attrelid, attname, attgenerated FROM pg_attribute WHERE
>> attgenerated IN ('v') and (attnotnull or not atthasdef);
> I don't understand what the purpose of testing attnotnull is. That is
> independent of attgenerated, I thi
On 03.12.24 15:15, jian he wrote:
-- check constraints
CREATE TABLE gtest20 (a int PRIMARY KEY, b int GENERATED ALWAYS AS (a
* 2) VIRTUAL CHECK (b < 50));
INSERT INTO gtest20 (a) VALUES (10); -- ok
INSERT INTO gtest20 (a) VALUES (30); -- violates constraint
ALTER TABLE gtest20 ALTER COLUMN b S
On 16.12.24 15:34, jian he wrote:
hi. some minor issues...
SET EXPRESSION AS
This form replaces the expression of a generated column. Existing data
in the column is rewritten and all the future changes will apply the new
generation expression.
On 11.12.24 07:49, jian he wrote:
On Fri, Nov 29, 2024 at 6:01 PM Peter Eisentraut wrote:
The purpose of check_modified_virtual_generated() for trigger functions
written in C. The prevent someone from inserting real values into the
trigger tuples, because they would then be processed by the re
On 04.12.24 05:55, jian he wrote:
On Fri, Nov 29, 2024 at 6:13 PM Peter Eisentraut wrote:
- Added support for virtual columns in trigger column lists. (For that,
I renamed ExecInitStoredGenerated() to ExecInitGenerated(), which
handles the computation of ri_extraUpdatedCols.)
why not dupli
On 08.01.25 09:22, Richard Guo wrote:
- Added support for ALTER TABLE ... SET EXPRESSION.
When using ALTER TABLE to set expression for virtual generated
columns, we don't enforce a rewrite, which means we don't have the
opportunity to check whether the new values for these columns could
cause an
On Fri, Nov 29, 2024 at 7:14 PM Peter Eisentraut wrote:
> Here is a new patch version, with several updates.
> - Added support for ALTER TABLE ... SET EXPRESSION.
When using ALTER TABLE to set expression for virtual generated
columns, we don't enforce a rewrite, which means we don't have the
opp
hi. some minor issues...
SET EXPRESSION AS
This form replaces the expression of a generated column. Existing data
in the column is rewritten and all the future changes will apply the new
generation expression.
the second sentence seems not to ap
On Fri, Nov 29, 2024 at 6:01 PM Peter Eisentraut wrote:
> The purpose of check_modified_virtual_generated() for trigger functions
> written in C. The prevent someone from inserting real values into the
> trigger tuples, because they would then be processed by the rest of the
> system, which would
On Fri, Nov 29, 2024 at 6:13 PM Peter Eisentraut wrote:
>
> - Added support for virtual columns in trigger column lists. (For that,
> I renamed ExecInitStoredGenerated() to ExecInitGenerated(), which
> handles the computation of ri_extraUpdatedCols.)
>
why not duplicate some code from ExecInitSt
-- check constraints
CREATE TABLE gtest20 (a int PRIMARY KEY, b int GENERATED ALWAYS AS (a
* 2) VIRTUAL CHECK (b < 50));
INSERT INTO gtest20 (a) VALUES (10); -- ok
INSERT INTO gtest20 (a) VALUES (30); -- violates constraint
ALTER TABLE gtest20 ALTER COLUMN b SET EXPRESSION AS (a * 100); --
viol
On 28.11.24 10:35, Peter Eisentraut wrote:
On 12.11.24 17:08, Peter Eisentraut wrote:
On 11.11.24 12:37, jian he wrote:
On Wed, Nov 6, 2024 at 12:17 AM Peter Eisentraut
wrote:
New patch version. I've gone through the whole thread again and looked
at all the feedback and various bug reports
On Fri, Nov 29, 2024 at 3:16 PM Peter Eisentraut wrote:
>
> On 14.11.24 10:46, Amit Kapila wrote:
> >> Moreover, we would have to implement some elaborate cross-checks if a
> >> table gets added to a publication. How would that work? "Can't add
> >> table x to publication because it contains a v
On 12.11.24 17:10, Peter Eisentraut wrote:
On 11.11.24 06:51, vignesh C wrote:
The patch needs to be rebased due to a recent commit 14e87ffa5c5.
done in v9
I
have verified the behavior of logical replication of row filters on
the virtual generated column, and everything appears to be functio
On 14.11.24 09:48, jian he wrote:
inspired by not-null and check check_modified_virtual_generated again.
in plpgsql_exec_trigger, we can:
/*
* In BEFORE trigger, stored generated columns are not computed yet,
* so make them null in the NEW row. (Only needed in UPDAT
On 13.11.24 04:30, jian he wrote:
in
transformColumnDefinition
we can add parser_errposition for the error report.
if (column->is_not_null && column->generated ==
ATTRIBUTE_GENERATED_VIRTUAL)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
On 12.11.24 17:50, Alvaro Herrera wrote:
On 12.11.24 09:49, jian he wrote:
On Wed, Nov 6, 2024 at 12:17 AM Peter Eisentraut wrote:
check_modified_virtual_generated, we can replace fastgetattr to
heap_attisnull? like:
// boolisnull;
// fastgetattr(tuple, i
On 14.11.24 10:46, Amit Kapila wrote:
Moreover, we would have to implement some elaborate cross-checks if a
table gets added to a publication. How would that work? "Can't add
table x to publication because it contains a virtual generated column
with a non-simple expression"? With row filters,
On 12.11.24 17:08, Peter Eisentraut wrote:
On 11.11.24 12:37, jian he wrote:
On Wed, Nov 6, 2024 at 12:17 AM Peter Eisentraut
wrote:
New patch version. I've gone through the whole thread again and looked
at all the feedback and various bug reports and test cases and made sure
they are all ad
On Tue, Nov 12, 2024 at 9:47 PM Peter Eisentraut wrote:
>
> On 10.11.24 04:16, Amit Kapila wrote:
> > The possible idea to replicate virtual generated columns is to compute
> > the corresponding expression before sending the data to the client. If
> > we can allow it in the row filter than why not
On Wed, Nov 13, 2024 at 11:30 AM jian he wrote:
>
> These 3 functions will call StoreRelNotNull to store the not-null constraint.
> StoreConstraints
> AddRelationNotNullConstraints
> AddRelationNewConstraints
>
> we can disallow not-null on virtual generated columns via these 3 functions.
> I gues
in
transformColumnDefinition
we can add parser_errposition for the error report.
if (column->is_not_null && column->generated ==
ATTRIBUTE_GENERATED_VIRTUAL)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("not-null constra
On 2024-Nov-12, Peter Eisentraut wrote:
> On 12.11.24 09:49, jian he wrote:
> > > On Wed, Nov 6, 2024 at 12:17 AM Peter Eisentraut
> > > wrote:
> > check_modified_virtual_generated, we can replace fastgetattr to
> > heap_attisnull? like:
> > // boolisnull;
> >
On 10.11.24 04:16, Amit Kapila wrote:
The possible idea to replicate virtual generated columns is to compute
the corresponding expression before sending the data to the client. If
we can allow it in the row filter than why not to publish it as well.
Row filters have pretty strong restrictions f
On 11.11.24 06:51, vignesh C wrote:
The patch needs to be rebased due to a recent commit 14e87ffa5c5.
done in v9
I
have verified the behavior of logical replication of row filters on
the virtual generated column, and everything appears to be functioning
as expected. One suggestion would be to
On 12.11.24 09:49, jian he wrote:
On Wed, Nov 6, 2024 at 12:17 AM Peter Eisentraut wrote:
RelationBuildPartitionKey
if (!isnull)
{
char *exprString;
Node *expr;
exprString = TextDatumGetCString(datum);
expr = stringToNode(exprString);
pfr
On 11.11.24 12:37, jian he wrote:
On Wed, Nov 6, 2024 at 12:17 AM Peter Eisentraut wrote:
New patch version. I've gone through the whole thread again and looked
at all the feedback and various bug reports and test cases and made sure
they are all addressed in the latest patch version. (I'll
On 07.11.24 11:02, Dean Rasheed wrote:
On Tue, 5 Nov 2024 at 16:17, Peter Eisentraut wrote:
New patch version.
In expand_generated_columns_in_expr():
+/*
+ * XXX For the benefit of triggers, make two passes, so it covers
+ * PRS2_OLD_VARNO and PRS2_NEW_VARNO.
+
> On Wed, Nov 6, 2024 at 12:17 AM Peter Eisentraut wrote:
> >
> > New patch version. I've gone through the whole thread again and looked
> > at all the feedback and various bug reports and test cases and made sure
> > they are all addressed in the latest patch version. (I'll send some
> > separa
On Wed, Nov 6, 2024 at 12:17 AM Peter Eisentraut wrote:
>
> New patch version. I've gone through the whole thread again and looked
> at all the feedback and various bug reports and test cases and made sure
> they are all addressed in the latest patch version. (I'll send some
> separate messages
On Tue, 5 Nov 2024 at 21:48, Peter Eisentraut wrote:
>
> On 30.09.24 04:09, Peter Eisentraut wrote:
> > I'm attaching a consolidated patch here, so we have something up to date
> > on the record. I haven't worked through all the other recent feedback
> > from Jian He yet; I'll do that next.
>
> N
On Tue, Nov 5, 2024 at 9:48 PM Peter Eisentraut wrote:
>
> On 30.09.24 04:09, Peter Eisentraut wrote:
> > I'm attaching a consolidated patch here, so we have something up to date
> > on the record. I haven't worked through all the other recent feedback
> > from Jian He yet; I'll do that next.
>
>
On Tue, 5 Nov 2024 at 16:17, Peter Eisentraut wrote:
>
> New patch version.
In expand_generated_columns_in_expr():
+/*
+ * XXX For the benefit of triggers, make two passes, so it covers
+ * PRS2_OLD_VARNO and PRS2_NEW_VARNO.
+ */
+node = expand_generated_c
On Tue, 5 Nov 2024 at 16:17, Peter Eisentraut wrote:
>
> New patch version.
What happened with the RLS support? It looks like you moved the code
to expand virtual generated columns back to the first loop in
fireRIRrules(), which doesn't work because RLS policies might contain
references to virtua
On 18.09.24 04:38, jian he wrote:
On Mon, Sep 16, 2024 at 5:22 PM jian he wrote:
in v7.
seems I am confused with the version number.
here, I attached another minor change in tests.
make
ERROR: invalid ON DELETE action for foreign key constraint containing
generated column
becomes
ERROR:
On 16.09.24 11:22, jian he wrote:
in v7.
doc/src/sgml/ref/alter_table.sgml
and column_constraint is:
section need representation of:
GENERATED ALWAYS AS ( generation_expr ) [VIRTUAL]
I have addressed this in patch v8.
in RelationBuildTupleDesc(Relation relation)
we need to add "constr->has_
On Mon, Sep 16, 2024 at 5:22 PM jian he wrote:
>
> in v7.
>
seems I am confused with the version number.
here, I attached another minor change in tests.
make
ERROR: invalid ON DELETE action for foreign key constraint containing
generated column
becomes
ERROR: foreign key constraints on virtual
in v7.
doc/src/sgml/ref/alter_table.sgml
and column_constraint is:
section need representation of:
GENERATED ALWAYS AS ( generation_expr ) [VIRTUAL]
in RelationBuildTupleDesc(Relation relation)
we need to add "constr->has_generated_virtual" for the following code?
if (constr->has_not_null
On 05.09.24 10:27, jian he wrote:
On Wed, Sep 4, 2024 at 4:40 PM Peter Eisentraut wrote:
Here is an implementation of this. It's much nicer! It also appears to
fix all the additional test cases that have been presented. (I haven't
integrated them into the patch set yet.)
I left the 0001 p
On 04.09.24 12:33, Dean Rasheed wrote:
I left the 0001 patch alone for now and put the new rewriting
implementation into 0002. (Unfortunately, the diff is kind of useless
for visual inspection.) Let me know if this matches what you had in
mind, please. Also, is this the right place in fireRIRr
On Wed, Sep 4, 2024 at 4:40 PM Peter Eisentraut wrote:
>
>
> Here is an implementation of this. It's much nicer! It also appears to
> fix all the additional test cases that have been presented. (I haven't
> integrated them into the patch set yet.)
>
> I left the 0001 patch alone for now and put
On Wed, 4 Sept 2024 at 09:40, Peter Eisentraut wrote:
>
> On 21.08.24 12:51, Dean Rasheed wrote:
> >>
> > Well what I was thinking was that (in fireRIRrules()'s final loop over
> > relations in the rtable), if the relation had any virtual generated
> > columns, you'd build a targetlist containing
On Thu, Aug 29, 2024 at 9:35 PM jian he wrote:
>
> On Thu, Aug 29, 2024 at 8:15 PM Peter Eisentraut wrote:
> >
> >
> > The new patch does some rebasing and contains various fixes to the
> > issues you presented. As I mentioned, I'll look into improving the
> > rewriting.
>
>
> based on your la
Hi,
On Thu, 29 Aug 2024 at 15:16, Peter Eisentraut wrote:
>
> I also committed the two patches that renamed the existing test files,
> so those are not included here anymore.
>
> The new patch does some rebasing and contains various fixes to the
> issues you presented. As I mentioned, I'll look
On Wed, Aug 21, 2024 at 6:52 PM Dean Rasheed wrote:
>
> On Wed, 21 Aug 2024 at 08:00, Peter Eisentraut wrote:
> >
> > On 08.08.24 20:22, Dean Rasheed wrote:
> > > Looking at the rewriter changes, it occurred to me that it could
> > > perhaps be done more simply using ReplaceVarsFromTargetList() f
On Thu, Aug 29, 2024 at 8:15 PM Peter Eisentraut wrote:
>
>
> > drop table if exists comment_test cascade;
> > CREATE TABLE comment_test (
> >id int,
> >positive_col int GENERATED ALWAYS AS (22) CHECK (positive_col > 0),
> >positive_col1 int GENERATED ALWAYS AS (22) stored CHECK (pos
drop table if exists gtest_err_1 cascade;
CREATE TABLE gtest_err_1 (
a int PRIMARY KEY generated by default as identity,
b int GENERATED ALWAYS AS (22),
d int default 22);
create view gtest_err_1_v as select * from gtest_err_1;
SELECT events & 4 != 0 AS can_upd, events & 8 != 0 AS can_ins,events &
On Wed, 21 Aug 2024 at 08:00, Peter Eisentraut wrote:
>
> On 08.08.24 20:22, Dean Rasheed wrote:
> > Looking at the rewriter changes, it occurred to me that it could
> > perhaps be done more simply using ReplaceVarsFromTargetList() for each
> > RTE with virtual generated columns. That function alr
On 08.08.24 20:22, Dean Rasheed wrote:
Looking at the rewriter changes, it occurred to me that it could
perhaps be done more simply using ReplaceVarsFromTargetList() for each
RTE with virtual generated columns. That function already has the
required wholerow handling code, so there'd be less code
1 - 100 of 113 matches
Mail list logo
