On Thu, Jul 21, 2005 at 07:10:03PM +1000, Ezequiel Tolnay wrote: > Thanks a lot, I've read the TODO and have now an idea of what is the > current trend or plans for future releases. > > Regarding my own needs, I'd be happy to "scratch my own itch", but > perhaps I should find some consensus before I engage myself in the task > of developing. And I would also need a little guidance in regards to how > to submit changes and all that. http://www.postgresql.org/developer/coding should help you get started. Also make sure to subscribe to -hackers and send an email there when you find something on the TODO list (or not on the list) that you'd like to work on. > * Scripting language: A very powerful feature in SQLServer is its > support of variables and control structures embedded in the SQL > language, thus allowing running complex scripts without the need to pack > them in a function and then running the function. This is especially > limiting in PG since it doesn't support the creation of temporary > functions. In MSSSQL, variables are prefixed with AT (@) symbols, must > be declared before they're used, live only within the prepared statement > and can be set using SET, SELECT and UPDATE. Also, the conditional > statements are only IF and WHILE, they support subqueries and function > calls in their expressions, and group statements using BEGIN and END. I > find prefixing variables thus is a lot less confusing and error prone > than the parameter alias and variables used in PL/pgSQL. For the > implementation on PG, I believe that perhaps it would be nice to use > curly brackets instead of BEGIN and END. Well, psql will do some of what you want, but yes, it would be useful if there was a means to run plpgsql code from the command line. There's been some talk about this, but nothing definative afaik. > * Allow FETCH command to be used with CREATE TABLE tab AS qry (in place > of qry) I'm not really clear on what you're looking for here.. > * Allow a function's result type to be defined in the function itself, > similarly to the way OUT parameters are constructed. If a type for it > must be created for this purpose, set it as a system object and handle > its recreation automatically upon CREATE OR REPLACE FUNCTION to avoid > the current catch-22 dependency issues. Or perhaps let function > returning a SETOF RECORD to have an implicit (undefined) result type, > thus avoiding having to specify the type dynamically in the caller > statement SELECT func(...) AS (...) Is there enough here for a TODO? > I hope a few of you will be interested in my proposals, so they get into > the TODO list. Once there, I'd be happy to contribute with some > development myself (either for these or other TODO items). I'm not a > proficient hacker with lots of time available, but I believe I'm a > fairly good programmer and I'm a Gentoo user so I have everything needed > to compile and build. But I believe I'll require a few months of > studying the code alone before I dare making any additions. So any hints > of how to become a PG developer to submit changes, and where to start > (or what documentation to read first) to have a fast head-start will be > highly appreciated. >From what I've seen, your best bet is to pick something (prefferably on the TODO list) that looks fairly simple, send an email to -hackers claiming it (and asking for any clarification, etc), and dive in. If you're interested in internals or new feature development you should absolutely subscribe to -hackers. Have I emphasised -hackers enough yet? :) -- Jim C. Nasby, Database Consultant decibel@xxxxxxxxxxx Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
