docs: Add docs for Relation literals by max-sixty · Pull Request #2605 · PRQL/prql

max-sixty · 2023-05-23T01:56:09Z

I've combined it with the from_text page, as I think they're similar (and I put these first since I think they're generally better).

One question — do we want any keyword for them — e.g. from_lit {...}? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

Is this a reasonable name? Or does it conjure someone saying "They're _literally_ tables" when seeing some large stools? I've combined it with the `from_text` page, as I think they're similar (and I put these first since I think they're generally better). One question — do we want any keyword for them — e.g. `from_lit {...}`? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

aljazerzen · 2023-05-23T07:48:52Z

If you want, you can use:

from {[a = 3]}
select a

... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'd say let's not add too much unnecessary functions here.

Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

for more information, see https://pre-commit.ci

max-sixty · 2023-05-23T08:07:49Z

If you want, you can use:
from {[a = 3]}
select a
... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'm going back & forth on this!

from seems incongruent applied to arrays — they're not table names — and from brings tables into the query.
But having it bare also seems out-of-place, (image below) — there's no transform bringing the array into the query....
But then we introduce another transform from_lit?!

FWIW having from was a question we went back & forth on in the very early days of PRQL — I originally just had artists. I think we were correct to make the change — queries look more cohesive with from artists than just artists.

Any thoughts from others?

Otherwise I guess we go with the existing state and see how we feel... I don't have much beyond aesthetics here, so we shouldn't wait at all.

FWIW let makes it look more reasonable (but we obv can't have different semantics inside & outside a declaration)

eitsupi · 2023-05-23T11:18:57Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)

Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

max-sixty · 2023-05-24T08:47:32Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)
Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

This resonates with me...

max-sixty · 2023-05-26T07:00:21Z

Merging this; with a note on us considering from...

max-sixty · 2023-05-23T01:56:09Z

I've combined it with the from_text page, as I think they're similar (and I put these first since I think they're generally better).

One question — do we want any keyword for them — e.g. from_lit {...}? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

Is this a reasonable name? Or does it conjure someone saying "They're _literally_ tables" when seeing some large stools? I've combined it with the `from_text` page, as I think they're similar (and I put these first since I think they're generally better). One question — do we want any keyword for them — e.g. `from_lit {...}`? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

aljazerzen · 2023-05-23T07:48:52Z

If you want, you can use:

from {[a = 3]}
select a

... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'd say let's not add too much unnecessary functions here.

Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

for more information, see https://pre-commit.ci

max-sixty · 2023-05-23T08:07:49Z

If you want, you can use:
from {[a = 3]}
select a
... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'm going back & forth on this!

from seems incongruent applied to arrays — they're not table names — and from brings tables into the query.
But having it bare also seems out-of-place, (image below) — there's no transform bringing the array into the query....
But then we introduce another transform from_lit?!

FWIW having from was a question we went back & forth on in the very early days of PRQL — I originally just had artists. I think we were correct to make the change — queries look more cohesive with from artists than just artists.

Any thoughts from others?

Otherwise I guess we go with the existing state and see how we feel... I don't have much beyond aesthetics here, so we shouldn't wait at all.

FWIW let makes it look more reasonable (but we obv can't have different semantics inside & outside a declaration)

eitsupi · 2023-05-23T11:18:57Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)

Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

max-sixty · 2023-05-24T08:47:32Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)
Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

This resonates with me...

max-sixty · 2023-05-26T07:00:21Z

Merging this; with a note on us considering from...

max-sixty · 2023-05-23T01:56:09Z

I've combined it with the from_text page, as I think they're similar (and I put these first since I think they're generally better).

One question — do we want any keyword for them — e.g. from_lit {...}? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

Is this a reasonable name? Or does it conjure someone saying "They're _literally_ tables" when seeing some large stools? I've combined it with the `from_text` page, as I think they're similar (and I put these first since I think they're generally better). One question — do we want any keyword for them — e.g. `from_lit {...}`? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

aljazerzen · 2023-05-23T07:48:52Z

If you want, you can use:

from {[a = 3]}
select a

... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'd say let's not add too much unnecessary functions here.

Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

for more information, see https://pre-commit.ci

max-sixty · 2023-05-23T08:07:49Z

If you want, you can use:
from {[a = 3]}
select a
... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'm going back & forth on this!

from seems incongruent applied to arrays — they're not table names — and from brings tables into the query.
But having it bare also seems out-of-place, (image below) — there's no transform bringing the array into the query....
But then we introduce another transform from_lit?!

FWIW having from was a question we went back & forth on in the very early days of PRQL — I originally just had artists. I think we were correct to make the change — queries look more cohesive with from artists than just artists.

Any thoughts from others?

Otherwise I guess we go with the existing state and see how we feel... I don't have much beyond aesthetics here, so we shouldn't wait at all.

FWIW let makes it look more reasonable (but we obv can't have different semantics inside & outside a declaration)

eitsupi · 2023-05-23T11:18:57Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)

Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

max-sixty · 2023-05-24T08:47:32Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)
Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

This resonates with me...

max-sixty · 2023-05-26T07:00:21Z

Merging this; with a note on us considering from...

max-sixty · 2023-05-23T01:56:09Z

I've combined it with the from_text page, as I think they're similar (and I put these first since I think they're generally better).

One question — do we want any keyword for them — e.g. from_lit {...}? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

Is this a reasonable name? Or does it conjure someone saying "They're _literally_ tables" when seeing some large stools? I've combined it with the `from_text` page, as I think they're similar (and I put these first since I think they're generally better). One question — do we want any keyword for them — e.g. `from_lit {...}`? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

aljazerzen · 2023-05-23T07:48:52Z

If you want, you can use:

from {[a = 3]}
select a

... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'd say let's not add too much unnecessary functions here.

Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

for more information, see https://pre-commit.ci

max-sixty · 2023-05-23T08:07:49Z

If you want, you can use:
from {[a = 3]}
select a
... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'm going back & forth on this!

from seems incongruent applied to arrays — they're not table names — and from brings tables into the query.
But having it bare also seems out-of-place, (image below) — there's no transform bringing the array into the query....
But then we introduce another transform from_lit?!

FWIW having from was a question we went back & forth on in the very early days of PRQL — I originally just had artists. I think we were correct to make the change — queries look more cohesive with from artists than just artists.

Any thoughts from others?

Otherwise I guess we go with the existing state and see how we feel... I don't have much beyond aesthetics here, so we shouldn't wait at all.

FWIW let makes it look more reasonable (but we obv can't have different semantics inside & outside a declaration)

eitsupi · 2023-05-23T11:18:57Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)

Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

max-sixty · 2023-05-24T08:47:32Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)
Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

This resonates with me...

max-sixty · 2023-05-26T07:00:21Z

Merging this; with a note on us considering from...

max-sixty · 2023-05-23T01:56:09Z

I've combined it with the from_text page, as I think they're similar (and I put these first since I think they're generally better).

One question — do we want any keyword for them — e.g. from_lit {...}? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

Is this a reasonable name? Or does it conjure someone saying "They're _literally_ tables" when seeing some large stools? I've combined it with the `from_text` page, as I think they're similar (and I put these first since I think they're generally better). One question — do we want any keyword for them — e.g. `from_lit {...}`? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

aljazerzen · 2023-05-23T07:48:52Z

If you want, you can use:

from {[a = 3]}
select a

... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'd say let's not add too much unnecessary functions here.

Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

for more information, see https://pre-commit.ci

max-sixty · 2023-05-23T08:07:49Z

If you want, you can use:
from {[a = 3]}
select a
... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'm going back & forth on this!

from seems incongruent applied to arrays — they're not table names — and from brings tables into the query.
But having it bare also seems out-of-place, (image below) — there's no transform bringing the array into the query....
But then we introduce another transform from_lit?!

FWIW having from was a question we went back & forth on in the very early days of PRQL — I originally just had artists. I think we were correct to make the change — queries look more cohesive with from artists than just artists.

Any thoughts from others?

Otherwise I guess we go with the existing state and see how we feel... I don't have much beyond aesthetics here, so we shouldn't wait at all.

FWIW let makes it look more reasonable (but we obv can't have different semantics inside & outside a declaration)

eitsupi · 2023-05-23T11:18:57Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)

Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

max-sixty · 2023-05-24T08:47:32Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)
Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

This resonates with me...

max-sixty · 2023-05-26T07:00:21Z

Merging this; with a note on us considering from...

max-sixty · 2023-05-23T01:56:09Z

I've combined it with the from_text page, as I think they're similar (and I put these first since I think they're generally better).

One question — do we want any keyword for them — e.g. from_lit {...}? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

Is this a reasonable name? Or does it conjure someone saying "They're _literally_ tables" when seeing some large stools? I've combined it with the `from_text` page, as I think they're similar (and I put these first since I think they're generally better). One question — do we want any keyword for them — e.g. `from_lit {...}`? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

aljazerzen · 2023-05-23T07:48:52Z

If you want, you can use:

from {[a = 3]}
select a

... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'd say let's not add too much unnecessary functions here.

Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

for more information, see https://pre-commit.ci

max-sixty · 2023-05-23T08:07:49Z

If you want, you can use:
from {[a = 3]}
select a
... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'm going back & forth on this!

from seems incongruent applied to arrays — they're not table names — and from brings tables into the query.
But having it bare also seems out-of-place, (image below) — there's no transform bringing the array into the query....
But then we introduce another transform from_lit?!

FWIW having from was a question we went back & forth on in the very early days of PRQL — I originally just had artists. I think we were correct to make the change — queries look more cohesive with from artists than just artists.

Any thoughts from others?

Otherwise I guess we go with the existing state and see how we feel... I don't have much beyond aesthetics here, so we shouldn't wait at all.

FWIW let makes it look more reasonable (but we obv can't have different semantics inside & outside a declaration)

eitsupi · 2023-05-23T11:18:57Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)

Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

max-sixty · 2023-05-24T08:47:32Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)
Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

This resonates with me...

max-sixty · 2023-05-26T07:00:21Z

Merging this; with a note on us considering from...

max-sixty · 2023-05-23T01:56:09Z

I've combined it with the from_text page, as I think they're similar (and I put these first since I think they're generally better).

One question — do we want any keyword for them — e.g. from_lit {...}? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

Is this a reasonable name? Or does it conjure someone saying "They're _literally_ tables" when seeing some large stools? I've combined it with the `from_text` page, as I think they're similar (and I put these first since I think they're generally better). One question — do we want any keyword for them — e.g. `from_lit {...}`? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

aljazerzen · 2023-05-23T07:48:52Z

If you want, you can use:

from {[a = 3]}
select a

... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'd say let's not add too much unnecessary functions here.

Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

for more information, see https://pre-commit.ci

max-sixty · 2023-05-23T08:07:49Z

If you want, you can use:
from {[a = 3]}
select a
... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'm going back & forth on this!

from seems incongruent applied to arrays — they're not table names — and from brings tables into the query.
But having it bare also seems out-of-place, (image below) — there's no transform bringing the array into the query....
But then we introduce another transform from_lit?!

FWIW having from was a question we went back & forth on in the very early days of PRQL — I originally just had artists. I think we were correct to make the change — queries look more cohesive with from artists than just artists.

Any thoughts from others?

Otherwise I guess we go with the existing state and see how we feel... I don't have much beyond aesthetics here, so we shouldn't wait at all.

FWIW let makes it look more reasonable (but we obv can't have different semantics inside & outside a declaration)

eitsupi · 2023-05-23T11:18:57Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)

Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

max-sixty · 2023-05-24T08:47:32Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)
Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

This resonates with me...

max-sixty · 2023-05-26T07:00:21Z

Merging this; with a note on us considering from...

max-sixty · 2023-05-23T01:56:09Z

I've combined it with the from_text page, as I think they're similar (and I put these first since I think they're generally better).

One question — do we want any keyword for them — e.g. from_lit {...}? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

Is this a reasonable name? Or does it conjure someone saying "They're _literally_ tables" when seeing some large stools? I've combined it with the `from_text` page, as I think they're similar (and I put these first since I think they're generally better). One question — do we want any keyword for them — e.g. `from_lit {...}`? I don't think we necessarily do, but wanted to raise it, since it's the only construction which can be directly in line now.

aljazerzen · 2023-05-23T07:48:52Z

If you want, you can use:

from {[a = 3]}
select a

... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'd say let's not add too much unnecessary functions here.

Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

for more information, see https://pre-commit.ci

max-sixty · 2023-05-23T08:07:49Z

If you want, you can use:
from {[a = 3]}
select a
... because from is already just a noop function. Its only utility is "pulling from database tables" instead of normal name resolution.

I'm going back & forth on this!

from seems incongruent applied to arrays — they're not table names — and from brings tables into the query.
But having it bare also seems out-of-place, (image below) — there's no transform bringing the array into the query....
But then we introduce another transform from_lit?!

FWIW having from was a question we went back & forth on in the very early days of PRQL — I originally just had artists. I think we were correct to make the change — queries look more cohesive with from artists than just artists.

Any thoughts from others?

Otherwise I guess we go with the existing state and see how we feel... I don't have much beyond aesthetics here, so we shouldn't wait at all.

FWIW let makes it look more reasonable (but we obv can't have different semantics inside & outside a declaration)

eitsupi · 2023-05-23T11:18:57Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)

Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

max-sixty · 2023-05-24T08:47:32Z

My preference is starting with from. (The word "lit" does not seem very clear to me.)
Given things like from foo.csv and from df (df is pandas.DataFame on Python) in DuckDB, I wouldn't mind putting something other than table name after from.

This resonates with me...

max-sixty · 2023-05-26T07:00:21Z

Merging this; with a note on us considering from...

max-sixty added 2 commits May 22, 2023 18:49

.
d9f17d4

max-sixty changed the title ~~docs: Add docs for "literal tables"~~docs: Add docs for Relation literalsMay 23, 2023

max-sixty mentioned this pull request May 23, 2023
feat: arrays and type system consolidation #2585
Merged

.
c452b72

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

max-sixtyand others added 4 commits May 23, 2023 00:55

Update web/book/src/language-features/relation-literals.md
63fc2ca
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
b7d0a75
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
a69b042
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

[pre-commit.ci] auto fixes from pre-commit.com hooks
793956a
for more information, see https://pre-commit.ci

aljazerzen approved these changes May 23, 2023
View reviewed changes

7d7f3d8

max-sixty added 4 commits May 25, 2023 23:30

Merge branch 'main' into docs-literal
4581588

873c1c6

bab692e

445f61d

max-sixty enabled auto-merge (squash) May 26, 2023 07:00

max-sixty merged commit 26cd9af into PRQL:mainMay 26, 2023

max-sixty deleted the docs-literal branch May 26, 2023 07:11

max-sixty added 2 commits May 22, 2023 18:49

.
d9f17d4

max-sixty changed the title ~~docs: Add docs for "literal tables"~~docs: Add docs for Relation literalsMay 23, 2023

max-sixty mentioned this pull request May 23, 2023
feat: arrays and type system consolidation #2585
Merged

.
c452b72

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

max-sixtyand others added 4 commits May 23, 2023 00:55

Update web/book/src/language-features/relation-literals.md
63fc2ca
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
b7d0a75
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
a69b042
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

[pre-commit.ci] auto fixes from pre-commit.com hooks
793956a
for more information, see https://pre-commit.ci

aljazerzen approved these changes May 23, 2023
View reviewed changes

7d7f3d8

max-sixty added 4 commits May 25, 2023 23:30

Merge branch 'main' into docs-literal
4581588

873c1c6

bab692e

445f61d

max-sixty enabled auto-merge (squash) May 26, 2023 07:00

max-sixty merged commit 26cd9af into PRQL:mainMay 26, 2023

max-sixty deleted the docs-literal branch May 26, 2023 07:11

max-sixty added 2 commits May 22, 2023 18:49

.
d9f17d4

max-sixty changed the title ~~docs: Add docs for "literal tables"~~docs: Add docs for Relation literalsMay 23, 2023

max-sixty mentioned this pull request May 23, 2023
feat: arrays and type system consolidation #2585
Merged

.
c452b72

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

max-sixtyand others added 4 commits May 23, 2023 00:55

Update web/book/src/language-features/relation-literals.md
63fc2ca
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
b7d0a75
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
a69b042
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

[pre-commit.ci] auto fixes from pre-commit.com hooks
793956a
for more information, see https://pre-commit.ci

aljazerzen approved these changes May 23, 2023
View reviewed changes

7d7f3d8

max-sixty added 4 commits May 25, 2023 23:30

Merge branch 'main' into docs-literal
4581588

873c1c6

bab692e

445f61d

max-sixty enabled auto-merge (squash) May 26, 2023 07:00

max-sixty merged commit 26cd9af into PRQL:mainMay 26, 2023

max-sixty deleted the docs-literal branch May 26, 2023 07:11

max-sixty added 2 commits May 22, 2023 18:49

.
d9f17d4

max-sixty changed the title ~~docs: Add docs for "literal tables"~~docs: Add docs for Relation literalsMay 23, 2023

max-sixty mentioned this pull request May 23, 2023
feat: arrays and type system consolidation #2585
Merged

.
c452b72

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

max-sixtyand others added 4 commits May 23, 2023 00:55

Update web/book/src/language-features/relation-literals.md
63fc2ca
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
b7d0a75
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
a69b042
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

[pre-commit.ci] auto fixes from pre-commit.com hooks
793956a
for more information, see https://pre-commit.ci

aljazerzen approved these changes May 23, 2023
View reviewed changes

7d7f3d8

max-sixty added 4 commits May 25, 2023 23:30

Merge branch 'main' into docs-literal
4581588

873c1c6

bab692e

445f61d

max-sixty enabled auto-merge (squash) May 26, 2023 07:00

max-sixty merged commit 26cd9af into PRQL:mainMay 26, 2023

max-sixty deleted the docs-literal branch May 26, 2023 07:11

max-sixty added 2 commits May 22, 2023 18:49

.
d9f17d4

max-sixty changed the title ~~docs: Add docs for "literal tables"~~docs: Add docs for Relation literalsMay 23, 2023

max-sixty mentioned this pull request May 23, 2023
feat: arrays and type system consolidation #2585
Merged

.
c452b72

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

max-sixtyand others added 4 commits May 23, 2023 00:55

Update web/book/src/language-features/relation-literals.md
63fc2ca
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
b7d0a75
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
a69b042
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

[pre-commit.ci] auto fixes from pre-commit.com hooks
793956a
for more information, see https://pre-commit.ci

aljazerzen approved these changes May 23, 2023
View reviewed changes

7d7f3d8

max-sixty added 4 commits May 25, 2023 23:30

Merge branch 'main' into docs-literal
4581588

873c1c6

bab692e

445f61d

max-sixty enabled auto-merge (squash) May 26, 2023 07:00

max-sixty merged commit 26cd9af into PRQL:mainMay 26, 2023

max-sixty deleted the docs-literal branch May 26, 2023 07:11

max-sixty added 2 commits May 22, 2023 18:49

.
d9f17d4

max-sixty changed the title ~~docs: Add docs for "literal tables"~~docs: Add docs for Relation literalsMay 23, 2023

max-sixty mentioned this pull request May 23, 2023
feat: arrays and type system consolidation #2585
Merged

.
c452b72

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

max-sixtyand others added 4 commits May 23, 2023 00:55

Update web/book/src/language-features/relation-literals.md
63fc2ca
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
b7d0a75
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
a69b042
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

[pre-commit.ci] auto fixes from pre-commit.com hooks
793956a
for more information, see https://pre-commit.ci

aljazerzen approved these changes May 23, 2023
View reviewed changes

7d7f3d8

max-sixty added 4 commits May 25, 2023 23:30

Merge branch 'main' into docs-literal
4581588

873c1c6

bab692e

445f61d

max-sixty enabled auto-merge (squash) May 26, 2023 07:00

max-sixty merged commit 26cd9af into PRQL:mainMay 26, 2023

max-sixty deleted the docs-literal branch May 26, 2023 07:11

max-sixty added 2 commits May 22, 2023 18:49

.
d9f17d4

max-sixty changed the title ~~docs: Add docs for "literal tables"~~docs: Add docs for Relation literalsMay 23, 2023

max-sixty mentioned this pull request May 23, 2023
feat: arrays and type system consolidation #2585
Merged

.
c452b72

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

max-sixtyand others added 4 commits May 23, 2023 00:55

Update web/book/src/language-features/relation-literals.md
63fc2ca
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
b7d0a75
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
a69b042
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

[pre-commit.ci] auto fixes from pre-commit.com hooks
793956a
for more information, see https://pre-commit.ci

aljazerzen approved these changes May 23, 2023
View reviewed changes

7d7f3d8

max-sixty added 4 commits May 25, 2023 23:30

Merge branch 'main' into docs-literal
4581588

873c1c6

bab692e

445f61d

max-sixty enabled auto-merge (squash) May 26, 2023 07:00

max-sixty merged commit 26cd9af into PRQL:mainMay 26, 2023

max-sixty deleted the docs-literal branch May 26, 2023 07:11

max-sixty added 2 commits May 22, 2023 18:49

.
d9f17d4

max-sixty changed the title ~~docs: Add docs for "literal tables"~~docs: Add docs for Relation literalsMay 23, 2023

max-sixty mentioned this pull request May 23, 2023
feat: arrays and type system consolidation #2585
Merged

.
c452b72

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

aljazerzen reviewed May 23, 2023
View reviewed changes

Comment threadweb/book/src/language-features/relation-literals.md Outdated

max-sixtyand others added 4 commits May 23, 2023 00:55

Update web/book/src/language-features/relation-literals.md
63fc2ca
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
b7d0a75
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

Update web/book/src/language-features/relation-literals.md
a69b042
Co-authored-by: Aljaž Mur Eržen <aljazerzen@users.noreply.github.com>

[pre-commit.ci] auto fixes from pre-commit.com hooks
793956a
for more information, see https://pre-commit.ci

aljazerzen approved these changes May 23, 2023
View reviewed changes

7d7f3d8

max-sixty added 4 commits May 25, 2023 23:30

Merge branch 'main' into docs-literal
4581588

873c1c6

bab692e

445f61d

max-sixty enabled auto-merge (squash) May 26, 2023 07:00

max-sixty merged commit 26cd9af into PRQL:mainMay 26, 2023

max-sixty deleted the docs-literal branch May 26, 2023 07:11

Uh oh!

Conversation

max-sixty commented May 23, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aljazerzen commented May 23, 2023

Uh oh!

Uh oh!

Uh oh!

Uh oh!

max-sixty commented May 23, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eitsupi commented May 23, 2023

Uh oh!

max-sixty commented May 24, 2023

Uh oh!

max-sixty commented May 26, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

max-sixty commented May 23, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aljazerzen commented May 23, 2023

Uh oh!

Uh oh!

Uh oh!

Uh oh!

max-sixty commented May 23, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eitsupi commented May 23, 2023

Uh oh!

max-sixty commented May 24, 2023

Uh oh!

max-sixty commented May 26, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

max-sixty commented May 23, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aljazerzen commented May 23, 2023

Uh oh!

Uh oh!

Uh oh!

Uh oh!

max-sixty commented May 23, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eitsupi commented May 23, 2023

Uh oh!

max-sixty commented May 24, 2023

Uh oh!

max-sixty commented May 26, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

max-sixty commented May 23, 2023•
edited
Loading

max-sixty commented May 23, 2023•
edited
Loading

max-sixty commented May 23, 2023•
edited
Loading

max-sixty commented May 23, 2023•
edited
Loading

max-sixty commented May 23, 2023•
edited
Loading

max-sixty commented May 23, 2023•
edited
Loading

max-sixty commented May 23, 2023•
edited
Loading

max-sixty commented May 23, 2023•
edited
Loading

max-sixty commented May 23, 2023•
edited
Loading

max-sixty commented May 23, 2023•
edited
Loading