Re: [Sender Address Forgery]Re: [HACKERS] generated columns

On 2019/04/08 20:50, Peter Eisentraut wrote: > On 2019-04-04 16:37, Amit Langote wrote: >> OK, thanks for explaining. We do allow DEFAULT to be specified on >> foreign tables, although locally-defined defaults have little meaning >> if the FDW doesn't allow inserts. Maybe same thing applies to

Re: [HACKERS] generated columns

On 2019-04-04 16:37, Amit Langote wrote: > OK, thanks for explaining. We do allow DEFAULT to be specified on > foreign tables, although locally-defined defaults have little meaning > if the FDW doesn't allow inserts. Maybe same thing applies to > GENERATED AS columns. > > Would it make sense

Re: [HACKERS] generated columns

On Thu, Apr 4, 2019 at 8:01 PM Peter Eisentraut wrote: > > On 2019-04-04 11:42, Amit Langote wrote: > > Hmm, I'm afraid we might get bug reports if we go with this. Why is it OK > > to get null in this case when a user explicitly asked for 'foo'? > > The way stored generated columns work on

Re: [HACKERS] generated columns

On 2019-04-04 11:42, Amit Langote wrote: > Hmm, I'm afraid we might get bug reports if we go with this. Why is it OK > to get null in this case when a user explicitly asked for 'foo'? The way stored generated columns work on foreign tables is that the to-be-stored value is computed, then given

Re: [HACKERS] generated columns

On 2019/04/04 16:52, Peter Eisentraut wrote: > On 2019-04-02 20:54, Erik Rijkers wrote: >> attached is run_ft.sh which creates a text file: /tmp/pg_head.txt >> then sets it up as a foreign table, and adds a generated column. >> >> Then selects a succesful select, followed by a error-producing

Re: [HACKERS] generated columns

On 2019-04-02 20:54, Erik Rijkers wrote: > attached is run_ft.sh which creates a text file: /tmp/pg_head.txt > then sets it up as a foreign table, and adds a generated column. > > Then selects a succesful select, followed by a error-producing select. I have committed a fix for this. -- Peter

Re: [HACKERS] generated columns

On 2019/04/03 3:54, Erik Rijkers wrote: > create schema if not exists "tmp"; > CREATE SCHEMA > create server if not exists "tmpserver" foreign data wrapper file_fdw; > CREATE SERVER > drop   foreign table if exists tmp.pg_head cascade; > DROP FOREIGN TABLE > create foreign table  

Re: [HACKERS] generated columns

On 2019-04-02 15:36, Erik Rijkers wrote: On 2019-04-02 14:43, Peter Eisentraut wrote: On 2019-04-01 10:52, Peter Eisentraut wrote: On 2019-03-31 05:49, Erik Rijkers wrote: STORED in a file_fdw foreign table still silently creates the column which then turns out to be useless on SELECT, with

Re: [HACKERS] generated columns

On 2019-04-02 14:43, Peter Eisentraut wrote: On 2019-04-01 10:52, Peter Eisentraut wrote: On 2019-03-31 05:49, Erik Rijkers wrote: STORED in a file_fdw foreign table still silently creates the column which then turns out to be useless on SELECT, with an error like: "ERROR: column

Re: [HACKERS] generated columns

On 2019-04-01 10:52, Peter Eisentraut wrote: > On 2019-03-31 05:49, Erik Rijkers wrote: >> STORED in a >> file_fdw foreign table still silently creates the column which then >> turns out to be useless on SELECT, with an error like: >> >> "ERROR: column some_column_name is a generated column >>

Re: [HACKERS] generated columns

On Mon, Apr 01, 2019 at 10:44:05PM +0900, Michael Paquier wrote: > Really? I thought on the contrary that it should work. This reminds > me of commit 59a884e9, which has been discussed here: > https://www.postgresql.org/message-id/20160212001846.gb29...@momjian.us And this remark makes little

Re: [HACKERS] generated columns

On Mon, Apr 01, 2019 at 10:53:27AM +0200, Peter Eisentraut wrote: > On 2019-03-31 15:22, Jeff Janes wrote: >> I can't do a same-major-version pg_upgrade across this commit, as the >> new pg_dump is trying to dump a nonexistent attgenerated column from the >> old database.  Is that acceptable

Re: [HACKERS] generated columns

On 2019-03-31 15:22, Jeff Janes wrote: > I can't do a same-major-version pg_upgrade across this commit, as the > new pg_dump is trying to dump a nonexistent attgenerated column from the > old database.  Is that acceptable collateral damage?  I thought we > usually avoided that breakage within the

Re: [HACKERS] generated columns

On 2019-03-31 05:49, Erik Rijkers wrote: > STORED in a > file_fdw foreign table still silently creates the column which then > turns out to be useless on SELECT, with an error like: > > "ERROR: column some_column_name is a generated column > DETAIL: Generated columns cannot be used in COPY."

Re: [HACKERS] generated columns

On 2019-03-30 10:24, Justin Pryzby wrote: > create_table.sgml now has this: > > https://www.postgresql.org/docs/devel/sql-createtable.html#id-1.9.3.85.6.2.18.1.2 > + > + The keyword STORED is required to signify that the > + column will be computed on write and will be stored on

Re: [HACKERS] generated columns

On Sat, Mar 30, 2019 at 4:03 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-03-26 20:50, Pavel Stehule wrote: > > It is great feature and I'll mark this feature as ready for commit > > Committed, thanks. > I can't do a same-major-version pg_upgrade across this commit,

Re: [HACKERS] generated columns

On 2019-01-16 22:40, Erik Rijkers wrote: If you add a generated column to a file_fdw foreign table, it works OK wih VIRTUAL (the default) but with STORED it adds an empty column, silently. I would say it would make more sense to get an error. VIRTUAL is gone, but that other issue is still

Re: [HACKERS] generated columns

On Sat, Mar 30, 2019 at 09:03:03AM +0100, Peter Eisentraut wrote: > On 2019-03-26 20:50, Pavel Stehule wrote: > > It is great feature and I'll mark this feature as ready for commit > > Committed, thanks. create_table.sgml now has this:

Re: [HACKERS] generated columns

so 30. 3. 2019 v 9:03 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > On 2019-03-26 20:50, Pavel Stehule wrote: > > It is great feature and I'll mark this feature as ready for commit > > Committed, thanks. > great feature, it reduce some necessity of triggers Regards

Re: [HACKERS] generated columns

On 2019-03-26 20:50, Pavel Stehule wrote: > It is great feature and I'll mark this feature as ready for commit Committed, thanks. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] generated columns

Hi út 26. 3. 2019 v 14:33 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > On 2019-03-20 03:51, Michael Paquier wrote: > > On Mon, Mar 18, 2019 at 03:14:09PM +0100, Pavel Stehule wrote: > >> postgres=# update foo set name = 'bbbxx' where id = 1; -- error > >> ERROR: no

Re: [HACKERS] generated columns

út 26. 3. 2019 v 19:52 odesílatel Pavel Stehule napsal: > Hi > > út 26. 3. 2019 v 14:33 odesílatel Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> napsal: > >> On 2019-03-20 03:51, Michael Paquier wrote: >> > On Mon, Mar 18, 2019 at 03:14:09PM +0100, Pavel Stehule wrote: >> >> postgres=#

Re: [HACKERS] generated columns

Hi út 26. 3. 2019 v 14:33 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > On 2019-03-20 03:51, Michael Paquier wrote: > > On Mon, Mar 18, 2019 at 03:14:09PM +0100, Pavel Stehule wrote: > >> postgres=# update foo set name = 'bbbxx' where id = 1; -- error > >> ERROR: no

Re: [HACKERS] generated columns

On Mon, Mar 18, 2019 at 03:14:09PM +0100, Pavel Stehule wrote: > postgres=# update foo set name = 'bbbxx' where id = 1; -- error > ERROR: no generation expression found for column number 3 of table > "foo" Yes I can see the problem after adding a generated column and dropping it on an INSERT

Re: [HACKERS] generated columns

Hi po 18. 3. 2019 v 8:35 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > Here is an updated patch with just the "stored" functionality, as > discussed. > > The actual functionality is much smaller now, contained in the executor. > Everything else is mostly DDL support,

Re: [HACKERS] generated columns

On 2019-01-15 08:13, Michael Paquier wrote: > +/* > + * Thin wrapper around libpq to obtain server version. > + */ > +static int > +libpqrcv_server_version(WalReceiverConn *conn) > This should be introduced in separate patch in my opinion (needed > afterwards for logirep). I have committed this

Re: [HACKERS] generated columns

On Wed, Feb 27, 2019 at 08:05:02AM +0100, Peter Eisentraut wrote: > There is something like that at the top of > src/test/regress/sql/generated.sql. I can expand that. I think you mean identity.sql. I would think that this would live better with some other sanity checks. I am fine with your

Re: [HACKERS] generated columns

On 2019-02-26 06:12, Michael Paquier wrote: > Hm. Does the SQL standard mention more features which could be merged > with stored values, virtual values, default expressions and identity > columns? I don't know the last trends in this area but I am wondering > if there are any other column

Re: [HACKERS] generated columns

On 2019-02-26 06:30, Michael Paquier wrote: > + if (attgenerated) > + { > + /* > +* Generated column: Dropping anything that the generation expression > +* refers to automatically drops the generated column. > +*/ > + recordDependencyOnSingleRelExpr(, expr,

Re: [HACKERS] generated columns

On Mon, Feb 25, 2019 at 09:46:35PM +0100, Peter Eisentraut wrote: > The virtual generated column part is still a bit iffy. I'm still > finding places here and there where virtual columns are not being > expanded correctly. Maybe it needs more refactoring. One big unsolved > issue is how the

Re: [HACKERS] generated columns

On Mon, Feb 25, 2019 at 09:51:52PM +0100, Peter Eisentraut wrote: > On 2019-01-15 08:13, Michael Paquier wrote: >> + boolhas_generated_stored; >> + boolhas_generated_virtual; >> } TupleConstr; >> Could have been more simple to use a char as representation here. > > Seems

Re: [HACKERS] generated columns

On 2019-01-15 08:13, Michael Paquier wrote: >>> Ah, the volatility checking needs some improvements. I'll address that >>> in the next patch version. >> >> ok > > The same problem happens for stored and virtual columns. This is fixed in v8. > It would be nice to add a test with composite

Re: [HACKERS] generated columns

On Thu, Jan 17, 2019 at 10:12:26AM +0900, Michael Paquier wrote: > Yes, something like that grows the memory and CPU usage rather > linearly: > CREATE TABLE tab (a int, b int GENERATED ALWAYS AS (a * 2) STORED); > INSERT INTO tab VALUES (generate_series(1,1)); The latest patch set got

Re: [HACKERS] generated columns

On 16/01/2019 22:40, Erik Rijkers wrote: > I couldn't compile v7-0001 and I am testing with the older v6-0001 (of > which I still had an instance). > > So the problem below may have been fixed already. > > If you add a generated column to a file_fdw foreign table, it works OK > wih VIRTUAL

Re: [HACKERS] generated columns

On Wed, Jan 16, 2019 at 02:14:41PM +0100, Peter Eisentraut wrote: > On 15/01/2019 08:13, Michael Paquier wrote: >> When testing a bulk INSERT into a table which has a stored generated >> column, memory keeps growing in size linearly, which does not seem >> normal to me. If inserting more tuples

Re: [HACKERS] generated columns

I couldn't compile v7-0001 and I am testing with the older v6-0001 (of which I still had an instance). So the problem below may have been fixed already. If you add a generated column to a file_fdw foreign table, it works OK wih VIRTUAL (the default) but with STORED it adds an empty column,

Re: [HACKERS] generated columns

On Thu, Nov 22, 2018 at 10:16 AM Peter Eisentraut wrote: > On 15/11/2018 15:10, Robert Haas wrote: > > I don't have a strong position on 1 vs. 2 vs. 3, but I do think it > > would be nicer not to use '\0' as a column value. I'd suggest you use > > 'n' or '0' or '-' or some other printable

Re: [HACKERS] generated columns

On 15/01/2019 08:13, Michael Paquier wrote: > When testing a bulk INSERT into a table which has a stored generated > column, memory keeps growing in size linearly, which does not seem > normal to me. If inserting more tuples than what I tested (I stopped > at 10M because of lack of time), it

Re: [HACKERS] generated columns

st 16. 1. 2019 v 9:26 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > On 15/01/2019 08:18, Pavel Stehule wrote: > > I would to have a mechanism for safe replacement of triggers of type > > > > if TG_TYPE = 'INSERT' THEN > > NEW.inserted := CURRENT_TIMESTAMP; > > ELSE

Re: [HACKERS] generated columns

On 15/01/2019 08:18, Pavel Stehule wrote: > I would to have a mechanism for safe replacement of triggers of type > > if TG_TYPE = 'INSERT' THEN >   NEW.inserted := CURRENT_TIMESTAMP; > ELSE IF TG_TYPE = 'UPDATE' THEN >   NEW.updated := CURRENT_TIMESTAMP; >  .. That kind of use is probably better

Re: [HACKERS] generated columns

út 15. 1. 2019 v 8:14 odesílatel Michael Paquier napsal: > On Sun, Jan 13, 2019 at 03:31:23PM +0100, Pavel Stehule wrote: > > ne 13. 1. 2019 v 10:43 odesílatel Peter Eisentraut < > > peter.eisentr...@2ndquadrant.com> napsal: > >> See here: > >> > >> >

Re: [HACKERS] generated columns

On Sun, Jan 13, 2019 at 03:31:23PM +0100, Pavel Stehule wrote: > ne 13. 1. 2019 v 10:43 odesílatel Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> napsal: >> See here: >> >> https://www.postgresql.org/message-id/b5c27634-1d44-feba-7494-ce5a31f91...@2ndquadrant.com > > I understand - it is

Re: [HACKERS] generated columns

ne 13. 1. 2019 v 10:43 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > On 11/01/2019 16:22, Pavel Stehule wrote: > > The documentation contains paragraph > > > > + The generation expression can only use immutable functions and > cannot > > + use subqueries or

Re: [HACKERS] generated columns

On 11/01/2019 16:22, Pavel Stehule wrote: > The documentation contains paragraph > > +  The generation expression can only use immutable functions and cannot > +  use subqueries or reference anything other than the current row > in any > +  way. > > It is necessary for stored

Re: [HACKERS] generated columns

Hi pá 11. 1. 2019 v 9:31 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > On 06/11/2018 13:27, Peter Eisentraut wrote: > > This is a small bug that I will fix in my next update. > > Time for another update. Lot's of rebasing, many things fixed, > including the ADD

Re: [HACKERS] generated columns

On 19/11/2018 19:54, Alvaro Herrera wrote: > It's unclear why you made generated columns on partitions unsupported. > I'd fix the limitation if possible, but if not, at least document it. This is explained here: + /* +* Generated columns in partition key expressions: +* +

Re: [HACKERS] generated columns

On 15/11/2018 15:10, Robert Haas wrote: > I don't have a strong position on 1 vs. 2 vs. 3, but I do think it > would be nicer not to use '\0' as a column value. I'd suggest you use > 'n' or '0' or '-' or some other printable character instead. I had carefully considered this when attidentity was

Re: [HACKERS] generated columns

Disclaimer: I had never seen this patch before. I did not participate in this feature design. I did not discuss this review with the author or anybody in 2ndQuadrant. I do not have any particular affective bonds with its author. I did not receive payment nor goods in exchange for this review.

Re: [HACKERS] generated columns

> > > 3. Radical alternative: Collapse everything into one new column. We > > could combine atthasdef and attgenerated and even attidentity into a new > > column. (Only one of the three can be the case.) This would give > > client code a clean break, which may or may not be good. The > >

Re: [HACKERS] generated columns

On Tue, Oct 30, 2018 at 4:35 AM Peter Eisentraut wrote: > 1. (current implementation) New column attgenerated contains 's' for > STORED, 'v' for VIRTUAL, '\0' for nothing. atthasdef means "there is > something in pg_attrdef for this column". So a generated column would > have atthasdef = true,

Re: [HACKERS] generated columns

On Tue, Oct 30, 2018 at 09:35:18AM +0100, Peter Eisentraut wrote: > 1. (current implementation) New column attgenerated contains 's' for > STORED, 'v' for VIRTUAL, '\0' for nothing. atthasdef means "there is > something in pg_attrdef for this column". > > 2. Alternative: A generated column has

Re: [HACKERS] generated columns

On Tue, 6 Nov 2018 at 13:16, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > Stored generated columns should be treated just like we'd treat a column > > value added by a trigger. > > > > e.g. if we had a Timestamp column called LastUpdateTimestamp we would > > want to send that

Re: [HACKERS] generated columns

On 06/11/2018 14:28, Simon Riggs wrote: > The simplest solution would be to exclude generated columns from the > replication stream altogether. > > > IMHO... > > Virtual generated columns need not be WAL-logged, or sent. right > Stored generated columns should be treated just like

Re: [HACKERS] generated columns

On Tue, 6 Nov 2018 at 04:31, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 31/10/2018 08:58, Erikjan Rijkers wrote: > > I have also noticed that logical replication isn't possible on tables > > with a generated column. That's a shame but I suppsoe that is as > > expected. > >

Re: [HACKERS] generated columns

On 31/10/2018 08:58, Erikjan Rijkers wrote: > I have also noticed that logical replication isn't possible on tables > with a generated column. That's a shame but I suppsoe that is as > expected. This is an issue we need to discuss. How should this work? The simplest solution would be to

Re: [HACKERS] generated columns

On 30/10/2018 16:14, Sergei Kornilov wrote: > Hi > > I applied this patch on top 2fe42baf7c1ad96b5f9eb898161e258315298351 commit > and found a bug while adding STORED column: > > postgres=# create table test(i int); > CREATE TABLE > postgres=# insert into test values (1),(2); > INSERT 0 2 >

Re: [HACKERS] generated columns

On 10/30/18, Peter Eisentraut wrote: > 3. Radical alternative: Collapse everything into one new column. We > could combine atthasdef and attgenerated and even attidentity into a new > column. (Only one of the three can be the case.) This would give > client code a clean break, which may or may

Re: [HACKERS] generated columns

Hi > OK, so the problem is COPY. > > Which means we have an issue with restore. We need to be able to pg_dump a > table with generated columns, then restore it afterwards. More generally, we > need to be able to handle data that has already been generated - the > "generate" idea should apply

Re: [HACKERS] generated columns

On Wed, 31 Oct 2018 at 08:29, Erik Rijkers wrote: > On 2018-10-31 09:15, Simon Riggs wrote: > > On Wed, 31 Oct 2018 at 07:58, Erikjan Rijkers wrote: > > > > > >> I have also noticed that logical replication isn't possible on tables > >> with a generated column. That's a shame but I suppsoe

Re: [HACKERS] generated columns

On 2018-10-31 09:15, Simon Riggs wrote: On Wed, 31 Oct 2018 at 07:58, Erikjan Rijkers wrote: I have also noticed that logical replication isn't possible on tables with a generated column. That's a shame but I suppsoe that is as expected. Couldn't see anything like that in the patch.

Re: [HACKERS] generated columns

On Wed, 31 Oct 2018 at 07:58, Erikjan Rijkers wrote: > I have also noticed that logical replication isn't possible on tables > with a generated column. That's a shame but I suppsoe that is as > expected. > Couldn't see anything like that in the patch. Presumably unintended consequence. The

Re: [HACKERS] generated columns

On 2018-10-30 16:14, Sergei Kornilov wrote: Hi I applied this patch on top 2fe42baf7c1ad96b5f9eb898161e258315298351 commit and found a bug while adding STORED column: postgres=# create table test(i int); CREATE TABLE postgres=# insert into test values (1),(2); INSERT 0 2 postgres=# alter table

Re: [HACKERS] generated columns

On Tue, Oct 30, 2018 at 09:35:18AM +0100, Peter Eisentraut wrote: > Attached is a new version of this patch. Thanks Peter for sending a new patch. I am still assigned as a reviewer, and still plan to look at it in more details. > It supports both computed-on-write and computed-on-read variants,

Re: [HACKERS] generated columns

On 30/10/2018 15:19, Erik Rijkers wrote: > On 2018-10-30 09:35, Peter Eisentraut wrote: > >> [v5-0001-Generated-columns.patch ] > > Hi, > > I couldn't get this to apply to current head. > > I tried: > > patch --dry-run --ignore-whitespace -p 0 -F 5 < > v5-0001-Generated-columns.patch > >

Re: [HACKERS] generated columns

Hi I applied this patch on top 2fe42baf7c1ad96b5f9eb898161e258315298351 commit and found a bug while adding STORED column: postgres=# create table test(i int); CREATE TABLE postgres=# insert into test values (1),(2); INSERT 0 2 postgres=# alter table test add column gen_stored integer GENERATED

Re: [HACKERS] generated columns

Hi > patch --dry-run --ignore-whitespace -p 0 -F 5 < > v5-0001-Generated-columns.patch > > and varied both -p and -F paramaters to no avail. Am I doing it wrong? I am able apply patch by command patch -p1 < v5-0001-Generated-columns.patch or by "git apply v5-0001-Generated-columns.patch", but

Re: [HACKERS] generated columns

On 2018-10-30 09:35, Peter Eisentraut wrote: [v5-0001-Generated-columns.patch ] Hi, I couldn't get this to apply to current head. I tried: patch --dry-run --ignore-whitespace -p 0 -F 5 < v5-0001-Generated-columns.patch and varied both -p and -F paramaters to no avail. Am I doing it

Re: [HACKERS] generated columns

On Wed, 27 Dec 2017 at 17:31, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 9/12/17 15:35, Jaime Casanova wrote: > > On 10 September 2017 at 00:08, Jaime Casanova > > wrote: > >> > >> During my own tests, though, i found some problems: > > Here is an updated patch that should

Re: [HACKERS] generated columns

On 2/1/18 21:25, Michael Paquier wrote: > On Thu, Feb 01, 2018 at 09:29:09AM -0500, Peter Eisentraut wrote: >> That would be nice. I'm going to study this some more to see what can >> be done. > > Thanks for the update. Note: Peter has moved the patch to next CF. I didn't get to updating this

Re: [HACKERS] generated columns

On Thu, Feb 01, 2018 at 09:29:09AM -0500, Peter Eisentraut wrote: > That would be nice. I'm going to study this some more to see what can > be done. By the way, cannot we consider just doing stored generated columns as a first cut? Both virtual and stored columns have their use cases, but

Re: [HACKERS] generated columns

On 1/31/18 08:18, Michael Paquier wrote: >> This also raises a question how a row type with generated columns should >> behave. I think a generation expression is a property of a table, so it >> does not apply in a row type. (Just like a default is a property of a >> table and does not apply in

Re: [HACKERS] generated columns

On Wed, Jan 31, 2018 at 10:18:04PM +0900, Michael Paquier wrote: > On Thu, Jan 25, 2018 at 10:26:55PM -0500, Peter Eisentraut wrote: >> On 1/19/18 00:18, Michael Paquier wrote: >>> +SELECT a, c FROM gtest12; -- FIXME: should be allowed >>> +ERROR: permission denied for function gf1 >> >> This

Re: [HACKERS] generated columns

On Thu, Jan 25, 2018 at 10:26:55PM -0500, Peter Eisentraut wrote: > On 1/19/18 00:18, Michael Paquier wrote: >> +SELECT a, c FROM gtest12; -- FIXME: should be allowed >> +ERROR: permission denied for function gf1 > > This is quite hard to fix and I would like to leave this for a future >

Re: [HACKERS] generated columns

On Sat, Jan 27, 2018 at 05:05:14PM -0500, Peter Eisentraut wrote: > This is expanded in the rewriter, so there is no context like that. > This is exactly how views work, e.g., > > create table t1 (id int, length int); > create view v1 as select id, length * 10 as length_in_nanometers >

Re: [HACKERS] generated columns

On 1/26/18 12:46, Robert Haas wrote: > On Thu, Jan 25, 2018 at 10:26 PM, Peter Eisentraut > wrote: >>> Does the SQL spec mention the matter? How do other systems >>> handle such cases? >> >> In Oracle you get the same overflow error. > > That seems awful. If a

Re: [HACKERS] generated columns

On Thu, Jan 25, 2018 at 10:26 PM, Peter Eisentraut wrote: >> Does the SQL spec mention the matter? How do other systems >> handle such cases? > > In Oracle you get the same overflow error. That seems awful. If a user says "SELECT * FROM tab" and it fails, how

Re: [HACKERS] generated columns

On 1/19/18 00:18, Michael Paquier wrote: > Instead of leaving bits for a feature that may or may not be > implemented, have you considered just blocking STORED at parsing level > and remove those bits? There is little point in keeping the equivalent > of dead code in the tree. So I would suggest a

Re: [HACKERS] generated columns

On Tue, Jan 16, 2018 at 09:55:16AM -0500, Peter Eisentraut wrote: > Here you go. Those changes actually meant that genbki.pl doesn't need > to be touched by this patch at all, so that's a small win. Thanks for the updated version. I have spent some time looking at what you are proposing here.

Re: [HACKERS] generated columns

On Wed, Dec 27, 2017 at 12:31:05PM -0500, Peter Eisentraut wrote: > On 9/12/17 15:35, Jaime Casanova wrote: >> On 10 September 2017 at 00:08, Jaime Casanova >> wrote: >>> >>> During my own tests, though, i found some problems: > > Here is an updated patch that

Re: [HACKERS] Re: [HACKERS] generated columns

On 12/31/2017 09:38 AM, Peter Eisentraut wrote: > On 12/30/17 16:04, Joe Conway wrote: >> + >> + The generation expression can refer to other columns in the table, but >> + not other generated columns. Any functions and operators used must be >> + immutable. References to other tables are not

Re: [HACKERS] Re: [HACKERS] generated columns

On 12/30/17 16:04, Joe Conway wrote: > + > + The generation expression can refer to other columns in the table, but > + not other generated columns. Any functions and operators used must be > + immutable. References to other tables are not allowed. > + > > Question -- when the "stored" kind of

Re: [HACKERS] Re: [HACKERS] generated columns

On 12/27/2017 09:31 AM, Peter Eisentraut wrote: > On 9/12/17 15:35, Jaime Casanova wrote: >> On 10 September 2017 at 00:08, Jaime Casanova >> wrote: >>> >>> During my own tests, though, i found some problems: > > Here is an updated patch that should address the

Re: [HACKERS] generated columns

On 9/12/17 15:35, Jaime Casanova wrote: > On 10 September 2017 at 00:08, Jaime Casanova > wrote: >> >> During my own tests, though, i found some problems: Here is an updated patch that should address the problems you have found. > also is interesting that in