"generated" as column/param flag

[Patrick Dowler]

Markus, all,

We probably need the one-line definition to go with the term, which
also provides the context. Maybe:

generated: values in this column are generated during output and query
constraints cannot be used

Maybe that definition will help us decide if this is the best term or
find a better one...
--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada

On Wed, 15 Apr 2026 at 08:36, Juaristi Campillo, Jon via registry
<registry at ivoa.net> wrote:
>
> Dear Markus, DAL, and Registry,
>
> (sorry for the duplicate email to those affected)
>
> 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?
> >
> >Thanks,
>
> 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