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.

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

cli: conditionally output unicode characters in the output of sql -e #7048

Merged
merged 1 commit into from
Jun 7, 2016

Conversation

knz
Copy link
Contributor

@knz knz commented Jun 4, 2016

Summary:

  • by default, sql -e always escapes strings that contain special
    characters. It also forcefully escapes strings containing double
    quotes and backslashes, so as to ease automated processing by other
    languages (ie. a string starting with a doublequote character in the
    output will always be the start of an escaped string.). This
    way issue cli: weirdness in SQL shell when printing a row #4315 is still addressed adequately.
  • a new flag --pretty is added to the sql sub-command, to print
    row data as pretty-formatted ASCII art tables.
  • when results are pretty-formatted (either in the interactive shell
    or with sql --pretty -e), graphic unicode and newline characters
    are printed without escaping. This keeps the fix to cli: printing of strings containing newlines in cli #6926.
  • new tests are added in cli_test.go (Example_sql_escape) to test
    escaped and non-escaped output when table and column names contain
    special characters.
  • the cli API renames runPrettyQuery to
    runQueryAndFormatResults, and extends it with an extra argument to
    specify pretty-printing.

(See issues/PRs #7045, #6926, #4354 and #4315 for background discussion.)

cc @bdarnell @mjibson @dt


This change is Reviewable

@tamird
Copy link
Contributor

tamird commented Jun 4, 2016

Reviewed 12 of 12 files at r1.
Review status: all files reviewed at latest revision, 1 unresolved discussion, all commit checks successful.


sql/show.go, line 118 [r1] (raw file):

          buf.WriteString(",")
      }
      buf.WriteString("\n\t")

👎 on this - if tablewriter does the wrong thing with tabs, can we report it upstream?


Comments from Reviewable

@knz
Copy link
Contributor Author

knz commented Jun 5, 2016

Review status: all files reviewed at latest revision, 1 unresolved discussion, all commit checks successful.


sql/show.go, line 118 [r1] (raw file):

Previously, tamird (Tamir Duberstein) wrote…

👎 on this - if tablewriter does the wrong thing with tabs, can we report it upstream?

Done: https://github.com/olekukonko/tablewriter/issues/36 Nevertheless I think the readability improvement still justifies implementing the workaround on our side until the upstream issue is fixed.

Comments from Reviewable

@tamird
Copy link
Contributor

tamird commented Jun 5, 2016

Review status: all files reviewed at latest revision, 1 unresolved discussion, all commit checks successful.


sql/show.go, line 118 [r1] (raw file):

Previously, knz (kena) wrote…

Done: olekukonko/tablewriter#36
Nevertheless I think the readability improvement still justifies implementing the workaround on our side until the upstream issue is fixed.

another thought: use [`tabwriter`](https://golang.org/pkg/text/tabwriter/) on the way into the tablewriter to get the right behaviour.

Comments from Reviewable

@knz knz force-pushed the cli-escape-term branch from 91e6d01 to ba3a6f8 Compare June 6, 2016 00:51
@knz
Copy link
Contributor Author

knz commented Jun 6, 2016

Review status: all files reviewed at latest revision, 1 unresolved discussion, all commit checks successful.


sql/show.go, line 118 [r1] (raw file):

Previously, tamird (Tamir Duberstein) wrote…

another thought: use tabwriter on the way into the tablewriter to get the right behaviour.

That was a good idea! I got it to work and thus reverted the change on SHOW CREATE. Thanks for the hint!

Comments from Reviewable

@tamird
Copy link
Contributor

tamird commented Jun 6, 2016

:lgtm:

Previously, knz (kena) wrote…

cli: conditionally output unicode characters in the output of sql -e

Summary:

  • by default, sql -e always escapes strings that contain special

    characters. It also forcefully escapes strings containing double

    quotes and backslashes, so as to ease automated processing by other

    languages (ie. a string starting with a doublequote character in the

    output will always be the start of an escaped string.). This

    way issue cli: weirdness in SQL shell when printing a row #4315 is still addressed adequately.

  • a new flag --pretty is added to the sql sub-command, to print

    row data as pretty-formatted ASCII art tables.

  • when results are pretty-formatted (either in the interactive shell

    or with sql --pretty -e), graphic unicode and newline characters

    are printed without escaping. This keeps the fix to cli: printing of strings containing newlines in cli #6926.

  • new tests are added in cli_test.go (Example_sql_escape) to test

    escaped and non-escaped output when table and column names contain

    special characters.

  • the cli API renames runPrettyQuery to

    runQueryAndFormatResults, and extends it with an extra argument to

    specify pretty-printing.

(See issues/PRs #7045, #6926, #4354 and #4315 for background discussion.)

cc @bdarnell @mjibson @dt


Reviewed 4 of 4 files at r2.
Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks pending.


cli/sql_util.go, line 276 [r2] (raw file):

  var buf bytes.Buffer
  w := new(tabwriter.Writer)
  w.Init(&buf, 4, 0, 1, ' ', 0)

nit: https://golang.org/pkg/text/tabwriter/#NewWriter


Comments from Reviewable

Summary:

- by default, `sql -e` always escapes strings that contain special
  characters. It also forcefully escapes strings containing double
  quotes and backslashes, so as to ease automated processing by other
  languages (ie. a string starting with a doublequote character in the
  output will always be the start of an escaped string.). This
  way issue cockroachdb#4315 is still addressed adequately.

- a new flag `--pretty` is added to the `sql` sub-command, to print
  row data as pretty-formatted ASCII art tables.

- when results are pretty-formatted (either in the interactive shell
  or with `sql --pretty -e`), graphic unicode and newline characters
  are printed without escaping. This keeps the fix to cockroachdb#6926.

- new tests are added in `cli_test.go` (`Example_sql_escape`) to test
  escaped and non-escaped output when table and column names contain
  special characters.

- the `cli` API renames `runPrettyQuery` to
  `runQueryAndFormatResults`, and extends it with an extra argument to
  specify pretty-printing.

(See issues/PRs cockroachdb#7045, cockroachdb#6926, cockroachdb#4354 and cockroachdb#4315 for background discussion.)
@knz knz force-pushed the cli-escape-term branch from ba3a6f8 to fdae424 Compare June 6, 2016 01:05
@knz
Copy link
Contributor Author

knz commented Jun 6, 2016

TFYR!

Previously, tamird (Tamir Duberstein) wrote…

:lgtm:


Review status: 9 of 10 files reviewed at latest revision, 1 unresolved discussion, some commit checks pending.


cli/sql_util.go, line 276 [r2] (raw file):

Previously, tamird (Tamir Duberstein) wrote…

nit: https://golang.org/pkg/text/tabwriter/#NewWriter

Done.

Comments from Reviewable

@tamird
Copy link
Contributor

tamird commented Jun 6, 2016

Reviewed 1 of 1 files at r3.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks pending.


Comments from Reviewable

@bdarnell
Copy link
Contributor

bdarnell commented Jun 7, 2016

:lgtm:

Previously, knz (kena) wrote…

TFYR!


Review status: :shipit: all files reviewed at latest revision, all discussions resolved, all commit checks successful.


Comments from Reviewable

@knz knz merged commit 3e7ed50 into cockroachdb:master Jun 7, 2016
@knz knz deleted the cli-escape-term branch June 7, 2016 17:10
@jseldess
Copy link
Contributor

Docs updated with cockroachdb/docs#373.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants