From: | <brook(at)biology(dot)nmsu(dot)edu> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, brook(at)biology(dot)nmsu(dot)edu, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: creating/accessing new runtime parameters |
Date: | 2003-09-24 20:02:17 |
Message-ID: | 16241.63561.948485.575270@viola.nmsu.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joe Conway writes:
> I had a patch about 80% complete to do this, but it was rejected. The
> comment was that I should use a temp table instead. I still think it
> would be useful myself. See this thread:
>
> http://archives.postgresql.org/pgsql-hackers/2002-12/msg00988.php
I'm sorry that was rejected. I can see that there might be error
checking issues, but perhaps that simply means some hooks to register
validation functions dynamically that could be called during SET.
As far as the general utility of it goes, I claim that it could be
quite valuable. I am thinking of complex new datatypes (that might be
dynamically loaded) that could benefit from having some run-time
variables specify some aspect of their behavior. Currently, we have
variables controlling the I/O of dates and times, for example.
Something analogous would potentially be useful for other datatypes.
Without the ability to dynamically add to the set of run-time
variables, it is impossible to write a datatype that has this
property.
In these cases, one really does want run-time variables, not temporary
tables, as the use exactly corresponds to the use for existing
variables: modifying the behavior of interal functions.
Cheers,
Brook
From | Date | Subject | |
---|---|---|---|
Next Message | Doug Royer | 2003-09-24 20:04:53 | Re: [HACKERS] Announcement: planned open source billing system demonstration |
Previous Message | Peter Eisentraut | 2003-09-24 19:33:17 | Re: <no subject> |