CONSTANT/NOT NULL/initializer properties for plpgsql record variables

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: CONSTANT/NOT NULL/initializer properties for plpgsql record variables
Date: 2018-01-25 16:00:37
Message-ID: CAKFQuwZn9C9e+BmTegqVvJgWCz5gZXWQSoLPPX09F7R+6V4i6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, January 25, 2018, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> The documentation currently says
>
> The CONSTANT option prevents the variable from being assigned to
> after initialization, so that its value will remain constant for
> the duration of the block.
>

While we don't really have the concept of mutable types other languages
do. Maybe just saying "from being assigned or mutated after
initialization" would suffice.

I don't see a desirable way to reinforce that the y in arr[y] is unenforced
documentation - in the code or docs - beyond what is already done. That
distinction doesn't usually come up and for those where it does the docs
will probably be an after-the-fact confirmation of observed behavior.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jesper Pedersen 2018-01-25 16:12:31 Re: unique indexes on partitioned tables
Previous Message Alvaro Herrera 2018-01-25 15:55:19 Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist