Re: [COMMITTERS] pgsql-server/ oc/src/sgml/catalogs.sgml rc/bac ...

On Tue, 6 Jan 2004, Tom Lane wrote:

> > Does this complete this TODO?
> > o Allow parameters to be specified by name and type during
> > definition
>
> Uh, no; the lack of documentation updates being one of the more glaring
> omissions. I should think that psql's \df needs some thought too, as
> well as the other PL languages besides plpgsql. What we've got here is
> just the core infrastructure for a feature, not the full feature.

Yes, my patch only handles pl/pgsql so far. The patch was big enough as it
was. I've not looked at it since I sent it in, I wanted to see what
happend with it before spending more time on it.

Things to do in the future is

1) Documentation. I pointed that out when I sent the patch I think.
I didn't do this partly because I had some problem building the docs
and partly because I'm not sure how to write it. It must of course be
done before a release.

2) Making it work for pl/sql. This involves changing the main parser
and maybe how the whole system for parameters work. In pg today the
expression parser supports variables of the form $<nat>. My plan
was to change this to $<ident> or whatever it becomes now when the
variables are not an ident anymore (not a problem).

This update can however change a lot if one want to do it correctly,
and support $<ident> variables in all places where we today support
$<nat>. For example to let the pl-languages supply values for named
arguments.

About the ident problem and the parser, I also got these shift/reduce
problems and just took the easy way out of using ident. It was not
wrong to use ident. it just was not optimal in that it rules out some
names that are now possible to use. It didn't worry me as much as it
seemed to worry Tom.

3) Other languages. I don't think I can/want update all of them. I feel
it's enough to put the core in and the language maintainers can make
use of this feature if it fits their language.

4) There are more places where one might want to extend it. For example
to handle the names for NEW/OLD in triggers. These names can now be
user defined. Not a big change, but it's possible now.

5) Probably something more that I've forgotten now.

I'm happy that the work is accepted. I spend a lot of time especially on
the catalog parts. That is a very fragile part of pg and it's not fun to
make changes there. There are assumptions in the code that is not clear to
a new coder.

ps I've just changed my email name to my real name which is Dennis
Björklund. I did that 5 years ago (still using pine) and got angry mails
back saying that my mails where broken. I hope the todays email programs
can handle non-ascii names better...

--
/Dennis Björklund