Re: creating/accessing new runtime parameters

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

In response to

Responses

Browse pgsql-hackers by date

  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>