"generated" as column/param flag

[Juaristi Campillo, Jon]

Dear Markus, DAL, and Registry,

On 2026/04/15 15:14 +0200, Markus Demleitner via dal <dal at ivoa.net>
wrote:

>Dear DAL, dear Registry,
>
>In the TAP issue https://github.com/ivoa-std/TAP/issues/11, Pat and I
>found that it would be really desirable to align the flags (indexed,
>std, principal, primary, nullable) we have for columns (in
>TAP_SCHEMA.columns) and TableParam-s (in VODataService tablesets).
>
>The immediate occasion was that we should have a way to signal "What
>you see on output in here is not necessarily what is in the database"
>or, in effect, "you cannot write constraints against this column".
>The classic use case from my end is that for most access_urls, DaCHS
>stores a relative path and produces an appropriate URL based on where
>it thinks it is running.  But there are many other use cases as well.
>
>To address that, I am proposing a flag in the sense of TAP issue #11
>for VODataService given it is nearing PR/RFC:
><https://github.com/ivoa-std/VODataService/pull/17>.
>
>We were thinking about a good literal for this flag; I came up with
>"unconstrainable", but that's a lot of letters and perhaps a bit
>over-specific.  What I propose now is "generated".
>
>So... what do people think?

I will go against the current here, sorry.

I think “generated”, “computed”, “derived” and such give an
impression that the column has been computed from others (as in
conversions, for instance). At least that is the nomenclature some SQL
tools use. Postgres, for instance:
https://www.postgresql.org/docs/current/ddl-generated-columns.html

What about “immutable”/“mutable”? I think it carries the meaning of
“What you see on output in here is not necessarily what is in the
database" or viceversa.

Best regards,
   Jon