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 >
