Skip to content
Erlang with SQL or not
Branch: master
Clone or download

Latest commit

artemeff Merge pull request #16 from szTheory/patch-1
Fix Hex package link in README
Latest commit ae18e87 Jan 29, 2020


Type Name Latest commit message Commit time
Failed to load latest commit information.
src bump version to 0.2.0 Dec 6, 2018
test handle type casts when parsing named params Nov 10, 2017
.gitignore make rebar3 compatible Jan 7, 2016


Erlang with SQL, inspired by yesql.


Suppose we have a database with a list of users, in Erlang we can use simple ORM (boss_db, texas), SQL builders (sqerl, mekao) or write SQL queries in Erlang code like this:

get_users(Conn) ->
    pgsql:squery(Conn, "SELECT * FROM users;").

Or something like that. yesql proposes to write SQL queries by your hands, but do it comfortably. Because most of ORM and SQL builders adds some accidental complexity to your software, ORM or builder should parse your code into SQL and then your RDBMS should parse SQL, also write a complex query in ORM - is pure hell, sometimes. That's why you should use pure SQL with some handy features, like that:

-- Get all users from database
-- :get_all_users
FROM users;

-- Just some description here
-- :get_user_by_id
FROM users
WHERE id = ?

-- Just some description here
-- :get_by_id
FROM :table
WHERE id = ?

In Erlang you can use these queries like functions:

> {ok, Queries} = eql:compile("queries/user.sql"). % with path to your queries file
> {ok, Q1} = eql:get_query(get_all_users, Queries).
> {ok, Q2} = proplists:get_value(get_user_by_id, Queries).
> {ok, Q3} = eql:get_query(get_by_id, Queries, [{table, "some_table"}]).
> Q1.
%> <<"SELECT * FROM users;">>
> Q2.
%> <<"SELECT * FROM users WHERE id = ?">>
> Q3.
%> [<<"SELECT * FROM ">>,"some_table",<<" WHERE id = ?">>]

Note: The named parameters like :table in the example above are not sanitized, so can be dangerous.

Not only for SQL

This library can provide anything you want with separated sections in file, eg for ENV-specific configuration:

-- ./env.config file
-- :dev
[{host, ""}].

-- :prod
[{host, ""}].

We can parse this file like SQL queries (but comments with % isn't supported yet, you can create PR for this feature :)).

> {ok, Config} = eql:compile("./env.config").
%> {ok,[{prod,<<"[{host, \"\"}].">>},
        {dev,<<"[{host, \"\"}].">>}]}

eql:compile/1 returns proplist of defined env configurations and we can parse each of them with simple helper:


load(Env, Config) ->
    parse(scan(proplists:get_value(Env, Config))).

scan(undefined) ->
scan(IoList) ->
    erl_scan:string(lists:flatten(io_lib:format("~s", [IoList]))).

parse({ok, Tokens, _}) ->
parse(_) ->

And use it like:

> config_helper:load(prod, Config).
%> {ok,[{host,""}]}
> config_helper:load(dev, Config).
%> {ok,[{host,""}]}

This module already exist and named eql_config for you.


  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request

If you make changes to the neotoma PEG file, src/eql_parse.peg you must run rebar3 as dev compile to rebuild src/eql_parse.erl, then run rebar3 commands like compile and eunit as normal.

You can’t perform that action at this time.