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

Add docs for SRF column accessors #3810

Merged
merged 1 commit into from
Oct 8, 2018
Merged

Add docs for SRF column accessors #3810

merged 1 commit into from
Oct 8, 2018

Conversation

rmloveland
Copy link
Contributor

@rmloveland rmloveland commented Oct 2, 2018

Fixes #3070

@cockroach-teamcity
Copy link
Member

This change is Reviewable

@rmloveland
Copy link
Contributor Author

Specific change is in the Table generator functions section.

v2.1/table-expressions.md Outdated Show resolved Hide resolved
@rmloveland
Copy link
Contributor Author

@jseldess mind giving this one a look again? thanks!

Copy link
Contributor

@knz knz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you

Copy link
Contributor

@jseldess jseldess left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, with a few questions.

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained


v2.1/table-expressions.md, line 189 at r2 (raw file):

{% include copy-clipboard.html %}
~~~ sql
> SELECT * FROM generate_series(1, 3)

While you're here, would you mind adding a semicolon here so this can be pasted and run directly in the shell?


v2.1/table-expressions.md, line 203 at r2 (raw file):

<span class="version-tag">New in v2.1:</span> Set-returning functions (SRFs) can now be accessed using `(SRF).x` where `x` is either:

- The name of a column returned from the function, or

nit: This isn't in our style guide, so it's up for debate, but I prefer to keep conjunctions out of bulleted lists. So I'd either introduce it a little differently (e.g., where x is either of the following:) or just integrate into the sentence (e.g., where x is either the name of a column... or ...).


v2.1/table-expressions.md, line 214 at r2 (raw file):

~~~
 x | n

Should the above statement produce this output for me? I'm getting:

root@127.0.0.1:63810/defaultdb> SELECT (i.keys).* FROM (SELECT information_schema._pg_expandarray(indkey) AS keys FROM pg_index) AS i;
  x | n
+---+---+
(0 rows)

Time: 2.935ms

@jseldess
Copy link
Contributor

jseldess commented Oct 8, 2018

Oh, also, is this PR fixing an issue? If so, can you use Fixes #<issue> or the like?

Copy link
Contributor Author

@rmloveland rmloveland left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jseldess!

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained


v2.1/table-expressions.md, line 189 at r2 (raw file):

Previously, jseldess (Jesse Seldess) wrote…

While you're here, would you mind adding a semicolon here so this can be pasted and run directly in the shell?

Fixed - thanks!


v2.1/table-expressions.md, line 203 at r2 (raw file):

Previously, jseldess (Jesse Seldess) wrote…

nit: This isn't in our style guide, so it's up for debate, but I prefer to keep conjunctions out of bulleted lists. So I'd either introduce it a little differently (e.g., where x is either of the following:) or just integrate into the sentence (e.g., where x is either the name of a column... or ...).

Fixed. Went with the "where x is one of the following: ..." formulation.


v2.1/table-expressions.md, line 214 at r2 (raw file):

Previously, jseldess (Jesse Seldess) wrote…

Should the above statement produce this output for me? I'm getting:

root@127.0.0.1:63810/defaultdb> SELECT (i.keys).* FROM (SELECT information_schema._pg_expandarray(indkey) AS keys FROM pg_index) AS i;
  x | n
+---+---+
(0 rows)

Time: 2.935ms

AFAICT the output varies depending on the contents of the current database. I think this is because information_schema is used for name lookups by IDEs and things.

Fixed by updating to add "For example (note that the output of queries against information_schema will vary per database):" to be (hopefully) clearer.

@rmloveland rmloveland merged commit 2439d79 into master Oct 8, 2018
@rmloveland rmloveland deleted the srf-accessors branch October 8, 2018 19:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants