Re: pgint.l

2019-01-17 Thread Abel Normand
t; attention to language itself and devs from pg community will advice >> something. What you think? >> >> Thanks. >> *From:* r...@tamos.net >> *Sent:* 16 January 2019 16:04 >> *To:* picolisp@software-lab.de >> *Reply to:* picolisp@software-lab.de >> *

Re: pgint.l

2019-01-17 Thread Michel Pelletier
b with them also, it probably will draw some > attention to language itself and devs from pg community will advice > something. What you think? > > Thanks. > *From:* r...@tamos.net > *Sent:* 16 January 2019 16:04 > *To:* picolisp@software-lab.de > *Reply to:* picolisp@software-lab

Re: pgint.l

2019-01-17 Thread Alexander Burger
On Thu, Jan 17, 2019 at 04:29:17PM +0100, Danilo Kordic wrote: > IMHO (PicoLisp) Namespaces _are_ "name" prefixes, for example "pg~" > instead of "pg-". > > [de pg []] # Empty Namespace. > [de pg~sym ~...] No, they are not. "pg~" is not part of the name. For example, one symbol may

Re: pgint.l

2019-01-17 Thread Danilo Kordic
IMHO (PicoLisp) Namespaces _are_ "name" prefixes, for example "pg~" instead of "pg-". [de pg []] # Empty Namespace. [de pg~sym ~...] Unfortunately Namespaces are not Association Lists, or Property Lists. Therefore they can not be processed by predefined procedures. I must point out

Re: pgint.l

2019-01-17 Thread Alexander Burger
Hi Abel, > Also mmamkin connected with me directly and also suggested to use prefix "pg-" > for whole library not only for public functions. I think that I probably > should to use namespaces to hide private functions. I would also recommend namespaces. > It would be nice if someone would

Re: pgint.l

2019-01-16 Thread Abel Normand
hat you think?Thanks. From: r...@tamos.netSent: 16 January 2019 16:04To: picolisp@software-lab.deReply to: picolisp@software-lab.deSubject: Re: pgint.l +1 for writing tests. +1 for using aw-‘s test harness. +1 for having a sane license. Huzzah! :) On Tue, 15 Jan 2019 21:11 +0300

Re: pgint.l

2019-01-16 Thread rick
lab.com/Abel-ze-Normand/pgint.l . I > tried to keep> its implementation as simple as possible. > > I'm open to your suggestions for future improvements and your > contributions. > -- > Best regards, Nail

Re: pgint.l

2019-01-16 Thread Mike
> I'm happy to announce that I released my small library to interfacing with > PostgreSQL -- > https://gitlab.com/Abel-ze-Normand/pgint.l Tested: centos7 psql-9.2.xx -> works voidlinux psql-9.6.xx -> works (mike) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: pgint.l

2019-01-16 Thread pd
Thanks for your great job In my opinion: > 1) should I use PostgreSQL error codes and throw exceptions based on them? So you could probably write: > > (catch 'PGintegrityError ...) > (catch 'PGconstraintError ...) You should. It's a good practice to handle exceptions and this allow developers

Re: pgint.l

2019-01-15 Thread Abel Normand
ith > > 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

Re: pgint.l

2019-01-15 Thread Alexander Burger
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 n

pgint.l

2019-01-15 Thread Abel Normand
Hello everyone, 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. I'm open to your suggestions for future improvements and your contributions. -- Best