Re: Re: Partitioning such that key field of inherited tables no longer retains any selectivity - Mailing list pgsql-general

From Tom Lane
Subject Re: Re: Partitioning such that key field of inherited tables no longer retains any selectivity
Date
Msg-id 1676.1399827069@sss.pgh.pa.us
Whole thread Raw
In response to Re: Partitioning such that key field of inherited tables no longer retains any selectivity  (David G Johnston <david.g.johnston@gmail.com>)
Responses Re: Re: Partitioning such that key field of inherited tables no longer retains any selectivity
List pgsql-general
David G Johnston <david.g.johnston@gmail.com> writes:
> Two approaches:
> 1. Standard virtual column name that, when used, gets rewritten into a
> constant that is stored at the table level.
> 2. A way for a column's value to be defined as a function call.

Recent versions of the SQL spec have a notion of "generated columns"
that I think subsumes both of these concepts.  We had a draft patch
awhile back that attempted to implement that feature.  It crashed
and burned for reasons I don't recall ... but certainly implementing
an already-standardized feature is more attractive than just inventing
behavior on our own.

            regards, tom lane


pgsql-general by date:

Previous
From: Ravi Roy
Date:
Subject: Re: Creating a role with read only privileges but user is allowed to change password
Next
From: Tom Lane
Date:
Subject: Re: Creating a role with read only privileges but user is allowed to change password