[MDEV-3053] LP:603186 - RQG: Virtual persistent columns not computed properly for default NULL values Created: 2010-07-08  Updated: 2015-02-02  Resolved: 2012-10-04

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Philip Stoev (Inactive) Assignee: Igor Babaev
Resolution: Fixed Votes: 0
Labels: Launchpad

Attachments: XML File LPexportBug603186.xml    

 Description   

In the example below, the virtual persistent column does not agree that the result from INTERVAL ( NULL , NULL ) is -1 . If the computation is executed without the aid of a virtual column, or if the virtual column is not persisted, the result is correct.

CREATE TABLE t1 ( f1 CHAR(32), f2 CHAR(32), v1 INT AS ( INTERVAL( f2 , NULL ) ) PERSISTENT );
INSERT INTO t1 ( f1 ) VALUES ( NULL );

SELECT INTERVAL(NULL , NULL), v1, ( INTERVAL( f2, NULL ) ) FROM t1;



 Comments   
Comment by Philip Stoev (Inactive) [ 2010-07-08 ]

Re: Virtual persistent columns not computed properly for default NULL values
Here is another example:

--disable_abort_on_error
DROP TABLE t1;
DROP TABLE t2;

CREATE TABLE t1 ( f1 CHAR(32) NOT NULL, v1 INT AS ( f1 ) PERSISTENT );
INSERT INTO t1 () VALUES ();

CREATE TABLE t2 ( f1 CHAR(32) NOT NULL, v1 INT AS ( f1 ) VIRTUAL );
INSERT INTO t2 () VALUES ();

SELECT f1, v1 FROM t1;
SELECT f1, v1 FROM t2;

Comment by Philip Stoev (Inactive) [ 2010-07-09 ]

Re: RQG: Virtual persistent columns not computed properly for default NULL values
What happens here is that if you use an INSERT that does not explicitly list all the columns in the table, some of the columns will get the default value. If such default values are then used in a virtual column computation, the result from the computation will be incorrect.

If you use an INSERT form where all fields are specified and thus no defaults kick in, virtual columns are computed correctly.

Comment by Rasmus Johansson (Inactive) [ 2011-12-13 ]

Launchpad bug id: 603186

Generated at Thu Feb 08 06:46:00 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.