Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> Would it be reasonable to label these fields for their likely 7.2
> functionality, rather than labeling them as they are now? Since this is
> the first time they are appearing, it would be nice to not have to
> change the names later...
I don't have a problem with renaming "datallowconn" to "datoffline"
(and reversing its sense) if you feel like doing that --- but please
note that these are only field names, they do not constrain whatever
command-level API we might put on top of the thing later. In any
case, I'm not sure it's a good idea to call the thing "datoffline"
when changing it doesn't actively throw off current connections.
Names that are intended to be suggestive should be accurately
suggestive, IMHO. (Maybe I should've called it datallownewconn.)
As for datistemplate, that is NOT the same as datreadonly, and when
we get around to supporting read-only databases there should be a
separate column for that, IMHO. datistemplate is actually a permissions
bit (are people who are neither superuser nor the database owner
allowed to clone a particular database?) and has nothing to do with
whether the DB is read-only. When we have read-only functionality,
I'd want to change CREATE DATABASE to require the source to be
both datistemplate and datreadonly --- but there are also substantial
uses for databases that are readonly but not templates. So we need
two bits. (Perhaps readonly status should apply to schemas, not
databases, anyway --- haven't studied that part of the spec yet...)
In short: I think datistemplate is fine as is. If you want to tweak
the name or behavior of datallowconn, go for it (though implementing a
command to set it might be a better plan than just tweaking the field
name...)
regards, tom lane