Re: what we need to use postgresql in the enterprise - Mailing list pgsql-general
From | Uwe C. Schroeder |
---|---|
Subject | Re: what we need to use postgresql in the enterprise |
Date | |
Msg-id | 200401142352.11859.uwe@oss4u.com Whole thread Raw |
In response to | Re: what we need to use postgresql in the enterprise ("Chris Travers" <chris@travelamericas.com>) |
List | pgsql-general |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 14 January 2004 11:05 pm, Chris Travers wrote: > From: <Bob.Henkel@hartfordlife.com> > > > First I would be happy to help get these things in postgresql. I'm not a > > c/c++ programming guru and would have to learn a bit before I could do > > the coding. I would be happy to test or talk about what's needed or > > anything like that. Or just keep the fire burning on these issues that I > > think are keeping postgresql from being the database to use for almost > > everything. > > I am in the "keep the fire burning" camp, though if I had the need and the > financing, I would add features as I needed them. > > > I love Postgresql and hope > > my viewpoint coming from Oracle can help improve things. > > I think that this is a perspective much valued on the list. I have no > Oracle experience, but it is still the tarket to beat. > > > I also think pl/pgsql is a better choice for stored procedures in general > > depending on the goal of the procedure. If the procedure is working with > > the database pl/pgsql seems to be the choice. I would rather use > > pl/pgsql and not have some perl and some python or some other language in > > my stored procedures. This may be more my opinion then the best way of > > doing things. But I like to keep things simple for any future person > > going to maintain the system. > > In general I am inclined to agree. However, there are a few exceptions > (mostly with untrusted languages, such as Pl/PerlU). They include: > 1: The ability to access the system outside the database. For example, > writing a logging function in PL/Perlu would allow you to log to a file, > and when this is logged, it will happen regardless of whether the > transaction commits or aborts (i.e. occurs outside the space of the normal > transaction). This could be used in creating a database application error > log separate from the PostgreSQL log. > 2: The ability to do text processing or other advanced features not easily > done in PLPGSQL. > 3: The ability to use network services, such as email, jabber, etc. > > Note that you can do all these things in C functions as well, but I would > rather write it in Perl than C :-) > > > I can see where you are coming from if you haven't used Oracle's > > exception handling. Here is a snippet of an exception handling block in > > one of my stored procedures. As you can see I don't need to check for > > errors after each piece of code. The exception block handles all > > exception handling. > > I > > > would say it's very clean and handles errors very well. this is a simple > > example but you can get the point. > > > > BEGIN > > > > code logic here > > code logic here > > code logic here > > code logic here > > code logic here > > > > EXCEPTION > > /* Not all of the non nullable fields passed had values */ > > WHEN e_mandatory_fields_null THEN > > r_return_cd := pkg_0100.g_return_missing_fields; > > pkg_0100.sp_get_error(r_return_cd,r_return_type,r_return_msg); > > /* Default error code called for all other errors */ > > WHEN others THEN > > pkg_0099.g_sql_code := SQLCODE; > > pkg_0099.g_sql_error_msg := SQLERRM; > > r_return_cd := pkg_0001.g_return_failure; > > pkg_0001.sp_log_error(r_return_cd,r_return_type,r_return_msg); > > > > END; > > Ok. I understand. This is extremely useful. I agree that this should be > done. Is it on the ToDo? That's a nice one. Reminds me of python try: except: structures - very useful indeed. It would make exception handling so much easier. I'd also say it would improve readability of the code. UC - -- Open Source Solutions 4U, LLC 2570 Fleetwood Drive Phone: +1 650 872 2425 San Bruno, CA 94066 Cell: +1 650 302 2405 United States Fax: +1 650 872 2417 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFABkarjqGXBvRToM4RArdNAJ9Cg4saorEpxirE9e0GGanZssG0xACeL7BP f5sRQ2TqKp5xC3ceOu2nFrE= =e9X6 -----END PGP SIGNATURE-----
pgsql-general by date: