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

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

From: Dennis Björklund <db(at)zigo(dot)dhs(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql-server/ oc/src/sgml/catalogs.sgml rc/bac ...
Date: 2004-01-07 05:58:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-hackers
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

    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

In response to


pgsql-hackers by date

Next:From: Chris TraversDate: 2004-01-07 06:10:23
Subject: OT: Copyright, was Re: Paypal WAS: PostgreSQL speakers needed for OSCON
Previous:From: Tom LaneDate: 2004-01-07 04:57:36
Subject: Re: Brokenness in parsing of pg_hba.conf

pgsql-committers by date

Next:From: Tom LaneDate: 2004-01-07 06:20:02
Subject: pgsql-server/src/pl/plpgsql/src pl_comp.c
Previous:From: Tom LaneDate: 2004-01-07 04:47:15
Subject: Re: pgsql-server/ oc/src/sgml/catalogs.sgml rc/bac ...

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