Re: Requests for Development

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 #

In response to

Responses

Browse pgsql-general by date

  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

Browse pgsql-sql by date

  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