Skip site navigation (1) Skip section navigation (2)

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 (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-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.



# 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


pgsql-sql by date

Next:From: Jan WieckDate: 2000-11-15 10:20:39
Subject: Re: Re: Requests for Development
Previous:From: Alvar FreudeDate: 2000-11-15 02:47:29
Subject: Re: Using Array-Values in subselect

pgsql-general by date

Next:From: Jan WieckDate: 2000-11-15 10:20:39
Subject: Re: Re: Requests for Development
Previous:From: igorDate: 2000-11-15 09:26:03
Subject: Dump problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group