[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed conventions for plpgsql coding for 1.3 and beyond

Hi Jeff;

There is some talk about using PL/Perl.  However, since there is also
some concern about unnecessary dependencies if people want to have
implementations in other languages (like Python), I am starting with
PL/Pgsql for my contributions since that seems the safest option :-)
Also, I personally haven't used PL/Perl  so I wouldn't be as efficient
at it.

Does PL/Perl have the ability to use named arguements?  If not, that
may not be a problem, but may cause us not to be able to use automatic
means to incorportate the logic into the system (which would just mean
that components would have to have more intelligence about the
variables supplied as arguments).  At any rate, I am not opposed to
allowing for PL/Perl contributions, but I would want to see how it is
to set up on Windows via Vanilla Perl.

Best Wishes,
Chris Travers

On 3/6/07, Jeff Kowalczyk <..hidden..> wrote:
--- Chris Travers <..hidden..> wrote:
> Since 1.3 will be our first release with substantial logic
> encapsulated in the database, I wanted to get discussion started on
> coding conventions.  Currently we are targetting the code for
> PostgreSQL 8.0 through 8.2 but want to ensure it is reasonably
> future-safe.

Can you discuss the criteria for procedural language selection? I'm curious to
know whether PL/pgSQL will be the sole procedural language used, or whether
PL/perl is expected to be used in some areas of the LedgerSMB in-database

I'm interested in this question mostly for installation and maintenance
reasons, e.g. the impact it has on installers, manual setup, dataset loading,
dependency package updates, etc. Thanks.

Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
Ledger-smb-devel mailing list