-
Notifications
You must be signed in to change notification settings - Fork 87
Description
I was thinking about more advanced queries and metadata, and some of them, along with some existing, are playing nicely with more traditional SQL syntax, but it could complicate writing queries for users, or very much complicate parsing and introduce unexpected behavior, if relaxed syntax remained.
Examples:
Arrays
is_image
, is_video
, etc could be global array variables containing extensions of files, so is_video = true
becomes something like ext in _video_exts
Relations
mp3_*
are implying that we parse only MP3 ID3 tags, but there are similar metadata available in OGG, FLAC and other files. We could havemp3
,vorbis_comments
, etc. relations with a single view liketags
coalescing data from columns in those relations, (btw, images and videos can have tags too).
Glob expansion for relations
select path, tags.* from ~/Music/
-- simple way to display all tags for audio files.
GROUP BY
Currently aggregation is total, we cannot define grouping criteria, if we could, such use-cases would be possible:
select tags.album, count(tags.title) from ~/Music/ group by tags.album
-- list number of titles in each album.select ext, format_size(sum(size)), count(ext) from ~/ group by ext
-- statistics of disc usage by file extension.
Aliases
From the top of my head would only affect naming of fields in JSON output, or CSV headers, if there were csv-with-headers output option, but with support for tuples, we could also do something like this:
select path, (width, height) as dimensions from ~/Pictures/ where ext in _image_exts into json
, which could produce output like this:
[
{
"path": "~/Pictures/cats.jpg",
"dimensions": {
"width": 1024,
"height": 768
},
},
{
"path": "~/Pictures/dogs.jpg",
"dimensions": {
"width": 640,
"height": 480
}
}
]