Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Inconsistencies in CREATE INDEX syntax #352

Closed
robertpang opened this issue Jun 30, 2018 · 1 comment
Closed

Inconsistencies in CREATE INDEX syntax #352

robertpang opened this issue Jun 30, 2018 · 1 comment
Assignees
@robertpang
Labels
kind/bug This issue is a bug

Comments

@robertpang
Copy link
Contributor

A couple of inconsistencies in CREATE INDEX syntax are observed:

  1. Contrary to the existing CREATE KEYSPACE and CREATE TABLE syntax where the WITH <properties> clause is at the end of the statement, the WITH CLUSTERING ORDER BY clause is not positioned at the end of the statement.
  2. The covered columns are denoted using the COVERING keyword. This compares to PostgreSQL and Microsoft SQL Server where they are denoted using the INCLUDE keyword.
@robertpang robertpang added the kind/bug This issue is a bug label Jun 30, 2018
@robertpang robertpang self-assigned this Jun 30, 2018
yugabyte-ci pushed a commit that referenced this issue Jun 30, 2018
@robertpang
#352: CREATE INDEX syntax changes
107b45e 
Summary:
Make a couple of changes to the CREATE INDEX sytax:

1. To be consistent with the existing CREATE KEYSPACE and CREATE TABLE syntax, move the "WITH CLUSTERING ORDER BY" clause to the end of the statement.
2. To be consistent with other databases, define covering columns using the "INCLUDE" keyword. The existing "COVERING" keyword is kept for compatibility.

Test Plan: Jenkins

Reviewers: mihnea

Reviewed By: mihnea

Subscribers: bogdan, yql, bharat

Differential Revision: https://phabricator.dev.yugabyte.com/D5086
@robertpang
Copy link
Contributor Author

Fixed in commit 107b45e.

jasonyb pushed a commit that referenced this issue Jun 11, 2024
PG-543: pg_stat_monitor: PostgreSQL's pg_stat_statements compatible v…
1286427 
…iew. (#352)

* PG-543: pg_stat_monitor: PostgreSQL's pg_stat_statements compatible view.

The view now carries all the columns as pg_stat_statements. This required fixing
data types of some of the columns, renaming a few, as well inclusion of new
columns to make the view fully compatible with pg_stat_statements.

* PG-543: pg_stat_monitor: PostgreSQL's pg_stat_statements compatible view.

Updating the upgrade sql file from 1.0 to 2.0 version linked with this issue
changes.

* PG-543: pg_stat_monitor: PostgreSQL's pg_stat_statements compatible view.

Updating datum calls to use UInt64 rather than Int64.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@robertpang robertpang

Labels
kind/bug This issue is a bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@robertpang