On Mon, 4 Sept 2023 at 00:26, Sergei Golubchik <s...@mariadb.org> wrote:
> 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. > Ok, and besides I've just found that INVISIBLE_SYSTEM is documented as > Can be queried explicitly in SELECT, otherwise invisible from anything Another plus to your point. -- Yours truly, Nikita Malyavin
_______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-le...@lists.mariadb.org
