From: | Jan Wieck <janwieck(at)Yahoo(dot)com> |
---|---|
To: | josh(at)agliodbs(dot)com |
Cc: | sqllist <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: Requests for Development |
Date: | 2000-11-15 09:53:02 |
Message-ID: | 200011150953.EAA01528@jupiter.jw.home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-sql |
Josh Berkus wrote:
> Tom, Bruce, Jan, etc.:
>
> [...]
>
> The rest of these requests apply to 7.2:
>
> 2. Stored Procedure functionality, i.e. outputting a full recordset from
> a function (or new structure, if functions are hard to adapt) based on
> the last SELECT statement passed to the function. An alternative would
> be to develop parameterized views, which might be the easiest path.
That's one of my favorite requests, and I'd be glad to have a
chance to start on it. Unfortunately the basic support in the
parser and other parts of the core engine isn't completely
planned yet, otherwise PL/pgSQL and PL/Tcl would've had this
from the very beginning.
> 3. Slightly more informative syntax error messages - frankly, just
> grabbing a little more text around the word or punctuation that
> triggered the error would be enormously helpful (I can't tell you the
> number of times I've gotten "Error at or near ')'" in a huge DDL
> statement.
That's a general problem of a lex/yacc parser and I'm not
sure how to force it to be a little more explanative. Maybe
we have a chance to grab something from the lex input buffer,
but IIRC that's unsafe because nobody knows how much of that
is already eaten into yacc tokens.
> 4. Use of named in addition to ordinal variables in PL/PGSQL functions
> (e.g. $account_type, $period instead of $1, $2).
Another general problem in the core engine. Dunno if we'll
have named arguments in the near future. In the meantime,
PL/pgSQL functions can use ALIAS to define the names for
arguments at the very top (it's a precompile time only thing,
so there is little to no performance impact). And PL/Tcl
functions could easily do a "set account_type $1" as well, so
I don't see a real problem for the readability of the
functions body.
To put the ball back into your yard, I'd like to make a
request too. There seem to be alot people using PL/pgSQL
and/or PL/Tcl extensively. OTOH there are newbies again and
again asking for a good tutorial, programming examples and so
on. Writing a good tutorial doesn't require a good backend
developer, IMHO an experienced SQL-programmer would be the
better guy anyway. During the past 4 years I've heard over
and over that people would like to contribute their $0.05 if
they only could code in C. That's an area where nobody needs
any C experience.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2000-11-15 10:20:39 | Re: Re: Requests for Development |
Previous Message | igor | 2000-11-15 09:26:03 | Dump problem |
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2000-11-15 10:20:39 | Re: Re: Requests for Development |
Previous Message | Alvar Freude | 2000-11-15 02:47:29 | Re: Using Array-Values in subselect |