On Sat, Jul 27, 2019 at 03:13:01PM +0200, Fulvio Scapin wrote:
> But, as I mentioned at the beginning, the inline table is the one leaving
> me slightly confused.
The syntax is *simple* (minimal features, which is not always the
same as: intuitive or "easy to use", but generally not too far off
the mark). Misunderstandings arise when one wishfully hopes for
or imagines features of the syntax that are not there.
> A non-shared, in-memory lookup table.
> Example: "inline:{ key=value, { key = text with whitespace or comma }}".
>
> Key-value pairs are separated by whitespace or comma; with a key-value
> pair inside "{}", whitespace is ignored after the opening "{", around the
> "=" between key and value, and before the closing "}".
> Inline tables eliminate the need to create a database file for just a few
> fixed elements. See also the static: map type
The only thing that's "missing" from the description is that the
braces have to match, this is because one can generally list multiple
tables:
virtual_alias_maps = inline:{...}, cdb:..., inline:{...}
and for that to work, there needs to be a sensible algorithm for
finding theclosing brace of the first "inline". But since there
is no support for literal "{" or "}" (i.e. no backslash or similar
"escape" characters are mentioned or implemented), and yet some
key-value pairs are enclosed in "{", "}", the braces must match.
> Below a few examples generated through postmap & tee & bash.
All the examples behave as expected given the general syntax. Yes,
an escape-character would make it possible to use non-matching
braces in the key and value. That's not presently possible.
--
Viktor.
