Re: Wishlist?

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@decibel.org
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?"