From: | "btober(at)computer(dot)org" <btober(at)broadstripe(dot)net> |
---|---|
To: | Tim Uckun <timuckun(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Shared Constants in PLPGSQL |
Date: | 2017-08-01 11:57:59 |
Message-ID: | 2011861715.327414083.1501588679613.JavaMail.zimbra@broadstripe.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
----- Original Message -----
> From: "Tim Uckun" <timuckun(at)gmail(dot)com>
> To: "pgsql-general" <pgsql-general(at)postgresql(dot)org>
> Sent: Tuesday, August 1, 2017 5:56:02 AM
> Subject: [GENERAL] Shared Constants in PLPGSQL
>
> What's the best way to deal with global constants in PLPGSQL. Currently I
> am putting them in a function with out parameters and then calling that
> function from every other function that needs them like this.
>
> CREATE OR REPLACE FUNCTION hashids.constants(
> OUT min_alphabet_length integer,
> OUT sep_div numeric,
> OUT guard_div numeric,
> OUT default_steps text,
> OUT default_alphabet text,
> OUT salt text)
>
> I am presuming that if I set this function as immutable the calls to this
> function will be cached and will not incur much overhead.
>
> Is there a better way to deal with this?
>
One alternative is to create a configuration values table to store application configuration parameters. This table generally has exactly one row. You can add new application configuration parameters easily as application requirements evolve by adding a new column of an appropriate data type. Then, when you need the configuration values in PLPSQL or anywhere for that matter, you do a simple SELECT statement. Also you, can update parameters if necessary (supposing if they are not actually *constants*) at run time very easily, too.
-- B
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2017-08-01 13:04:08 | Re: Shared Constants in PLPGSQL |
Previous Message | Tim Uckun | 2017-08-01 09:56:02 | Shared Constants in PLPGSQL |