On Thu, Apr 4, 2019 at 8:01 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2019-04-04 11:42, Amit Langote wrote:
> > Hmm, I'm afraid we might get bug reports if we go with this. Why is it OK
> > to get null in this case when a user explicitly asked for 'foo'?
>
> The way stored generated columns work on foreign tables is that the
> to-be-stored value is computed, then given to the foreign table handler,
> which then has to store it, and then return it later when queried.
> However, since the backing store of a foreign table is typically
> modifiable directly by the user via other channels, it's possible to
> create situations where actually stored data does not satisfy the
> generation expression. That is the case here. I don't know of a
> principled way to prevent that. It's just one of the problems that can
> happen when you store data in a foreign table: You have very little
> control over what data actually ends up being stored.
OK, thanks for explaining. We do allow DEFAULT to be specified on
foreign tables, although locally-defined defaults have little meaning
if the FDW doesn't allow inserts. Maybe same thing applies to
GENERATED AS columns.
Would it make sense to clarify this on CREATE FOREIGN TABLE page?
Thanks,
Amit
