On Tue, Aug 1, 2017 at 8:29 AM, Tim Uckun wrote:
> In my case I don't expect these constants to be changed on a regular basis.
> They will be set just once and that's it. I was thinking it would be just as
> easy to set them in a proc as it would be to set them in a table. By putting
> them in an
In my case I don't expect these constants to be changed on a regular basis.
They will be set just once and that's it. I was thinking it would be just
as easy to set them in a proc as it would be to set them in a table. By
putting them in an immutable proc I can hopefully save a couple of compute
cy
On Tue, Aug 1, 2017 at 8:04 AM, Merlin Moncure wrote:
> re-evaluate. The main advantage over your approach is that you don't
> have to modify multiple things every time you add a new config values;
> just add a column and replace the function.
This can be automated too, via event triggers:
https
On Tue, Aug 1, 2017 at 4:56 AM, Tim Uckun wrote:
> 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 hash
- Original Message -
> From: "Tim Uckun"
> To: "pgsql-general"
> 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
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,
OU
