[erlang-questions] [ANN] Asynchronous PostgreSQL driver

Dmitry Demeshchuk demeshchuk@REDACTED
Tue Nov 8 06:52:47 CET 2011


On Tue, Nov 8, 2011 at 8:40 AM, Anton Lebedevich <mabrek@REDACTED> wrote:
> On 11/01/2011 11:59 AM, Dmitry Demeshchuk wrote:
>> 1. It's kind of weird that you use such a sequence:
>>
>> {ok, C} = pgsql_sock:start_link(),
>> pgsql_sock:connect(C, Host, Port, ...)
>>
>> It would be more consistent if you passed all the necessary parameters
>> into pgsql_sock:start_link and initiated the connection in
>> pgsql_sock:init/1, so it will look like:
>>
>> {ok, Pid} = pgsql_sock:start_link(Options)
>>
>> where Options is a proplist.
>
> Good idea, will try it.
> start_link then connect sequence came from original implementation, I
> haven't changed it yet.
>
>> 2. Using a proplist of options instead of listing these options (like
>> host and port) as mandatory parameters may be reasonable.
>
> It came from original implementation too.
> BTW, if I use proplists in this case how can I requre some parameters
> (e.g. host and port) to be passed?

There are many ways.
Firstly, you can actually let *not* passing them and set the default
record fields to "localhost" and 5432.
However, if you want to make them mandatory, you can:
1. Just leave them be, and don't set default record fields values. In
this case they'll be both undefined and you'll get an error.
2. You can go further and, say, write this:

State#state.host =/= undefined orelse throw(nohost),
State#state.port =/= undefined orelse throw(noport),

3. Use lists:keyfind/3 to parse these very values (probably, the least
convenient way).

Also, please consider a parse transform I've recently written for such
cases. It creates the parse_options/2 function for you, so you won't
have to write it yourself: https://github.com/doubleyou/ptrans

>
>> 4. I'd also consolidate pgsql_binary and pgsql_wire modules. Probably,
>> also moved the functions with binary pattern matchings from pgsql_sock
>> too. After all, the entire purpose is to describe the PostgreSQL
>> protocol and it might be more convenient if it's handled by a single
>> module.
>
> There are two ideas behind them: wire protocol and column format.
> pgsql_wire decodes and encodes whole messages. pgsql_binary only deals
> with columns in binary format inside DataRow messages.
> I'm considering adding pgsql_text module to handle columns in text
> format, it will save one database roundtrip on equery.
>
> Regards,
> Anton Lebedevich.
>



-- 
Best regards,
Dmitry Demeshchuk



More information about the erlang-questions mailing list