"generated" as column/param flag

[Markus Demleitner]

Dear Joshua,

On Wed, Apr 15, 2026 at 02:45:08PM +0000, Joshua Fraustro via dal wrote:
> The only things I could offer as alternatives, in order of quality,
> I think are:
>
> “computed”
> “derived”
> “dynamic”
>
> The problem with all three of those is something that we run into
> with a number of things in TAP_SCHEMA, which is the distinction
> between whether we’re actually describing the data or what a user
> can meaningfully do with it.

Right.  My approach to questions like this tends to be: "Take the
user perspective".  This is because the VO is still dominated by data
providers, and hence that perspective tends to be under-represented.
More importantly, my experience with VO standards is that they
are best when they are constructed from what the users are supposed
to do with them and worst when data providers think about all the
great things they would want to tell their users.

That inspired my first suggestion, unconstrainable.

> If it’s about the data, the above might be a hair better. But if
> it’s simply about whether a user can filter​ on the data,
> might I suggest just, filterable​ ?

I don't like filterable much because that's the default and we'd have
to put it into the flags of most columns, which I'd like to avoid.
The special case hence would be "unfilterable", which is almost as
long and ugly as unconstrainable but IMHO a bit less precise because
it's constraints that you can't write (in ADQL), whereas I think
"filter" just doesn't exist in VO lingo (outside of VOEvent?) yet.

In the PR, the cute option "no-where" came up.  The more I think of it,
the more I like it.  Admittedly, it's strongly geared towards
SQL-like query languages, but I don't consider that a major wart, as
that's the model for almost anything out there (cf. SPARQL).  And
it's something that shouldn't cause any false associations.

As to Jon's proposal “immutable”/“mutable”...  Well, "mutable" has a
strong meaning already that is quite a bit away from what we are
struggling with here.  So I'd prefer generated over that.

Well: I've updated the PR and rebased it to a previous VODataService
PR that already had all the whitespace noise (thanks, Mark) so it's a
lot more readable now.  I've kept "generated" as literal for now but
changed the definition to Pat's proposal:

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

While I think that's *a bit* overspecific because I'd like to use
this flag also when I, say, store some binary data in a database
column and want to tell people there's no meaningful way to
constraint that for the time being, it feels more understandable to
me than my previous attempt.

So... are there people who absolutely couldn't live with "generated"?
And are the improvements on Pat's definition?

Thanks,

          Markus