Hi Alexander, thanks for your suggestion. I've completely forgot about
(pass) behaviour, I would include this change in next patch.

There are some questions that remained for me unanswered during development:

1) should I use PostgreSQL error codes and throw exceptions based on them?
So you could probably write:

(catch 'PGintegrityError ...)
(catch 'PGconstraintError ...)

And so forth. I did not find such error handling somewhat useful from my
previous experience so I did not include it in initial release.

2) probably I have to extract pg types <-> pico types translation to some
kind of abstract table to support extensibility? So devs could add their
own types to translation table without encoding-decoding by hand.

Thanks!

On Tue, 15 Jan 2019, 21:50 Alexander Burger <a...@software-lab.de wrote:

> Hi Abel,
>
> > I'm happy to announce that I released my small library to interfacing
> with
> > PostgreSQL -- https://gitlab.com/Abel-ze-Normand/pgint.l . I tried to
> keep
> > its implementation as simple as possible.
>
> Cool, many thanks!
>
> I cannot comment on things PostgreSQL, as I never used it. But formally
> the code
> looks good. Just one minor optimization comes to mind:
>
> There are two cases where variable arguments are passed to another
> function,
> e.g. in:
>
>    (de exec-libpq (Cmd RetTyp . @)
>       (apply native (conc (list "libpq.so" Cmd RetTyp) (rest))) )
>
> As (list ...) and (rest) build new lists, just to pass them to 'apply', it
> is
> better to directly 'pass' the arguments to that function. With that we get:
>
>    (de exec-libpq (Cmd RetTyp . @)
>       (pass native "libpq.so" Cmd RetTyp) )
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Reply via email to