Hi, Nikita,

On Sep 03, Nikita Malyavin wrote:
> One more stack of questions:
>
> > > +show columns from t1;
> > > +Field        Type    Null    Key     Default Extra
> > > +id   int(11) NO      PRI     NULL
> > > +s    timestamp(6)    NO              NULL
> > > +e    timestamp(6)    NO              NULL
> > > +select * from information_schema.periods where table_schema = 'test';
> > > +TABLE_CATALOG        TABLE_SCHEMA    TABLE_NAME      PERIOD START_COLUMN_NAME       END_COLUMN_NAME
> > > +def  test    t2      SYSTEM_TIME     row_start       row_end
> >
> > I don't think so, they're INVISIBLE_SYSTEM. for all practical purposes they
> > don't exist as columns in the table. Shouldn't be shown either.
> > But don't remove this test, let's keep it to show that row_start/row_end
> > are
> > *not* shown here.
> > And add table t3 with full standard definition of period for system_time.
> > it should be shown all right.
>
> The columns -- I've checked -- can be accessed in SELECT, so why not
> show it?

They can be accessed by SELECT, but they aren't _columns_.
No other I_S table show them, SHOW CREATE doesn't show them.
They're pseudo-columns, like, for example, ROWID in Oracle.

> What should be the value then? An empty string? Or make it NULLable?
> The period itself is also accessible in SELECT, so I suppose it should
> be shown.

No. If SHOW CREATE TABLE doesn't show something - this something doesn't
exist as an object in the table, so information_schema.periods should
not show it either.

> Can be queried explicitly in SELECT, otherwise invisible from anything 

Another plus to your point.