Re: Should we document IS [NOT] OF? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Should we document IS [NOT] OF?
Date
Msg-id 1052846.1605802012@sss.pgh.pa.us
Whole thread Raw
In response to Re: Should we document IS [NOT] OF?  (Joe Conway <mail@joeconway.com>)
Responses Re: Should we document IS [NOT] OF?  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> Here is a link to previous list discussions:
> https://www.postgresql.org/message-id/45DA44F3.3010401%40joeconway.com

Ah, thanks, I was intending to go do some searching for that.

So at this point this has been re-debated at least three times.
I think it's time to put it out of its misery.  You can get
equivalent behavior using something like
   pg_typeof(foo) in ('int'::regtype, 'float8'::regtype)
so we've got the "another way to do it" covered.  And I'm
still convinced that the existing implementation is not
anywhere near per-spec.  The issue about NULL is somewhat
minor perhaps, but the real problem is that I think the
spec intends "foo is of (sometype)" to return true if foo
is of any subtype of sometype.  We don't have subtypes in
the way SQL intends, but we do have inheritance children
which are more or less the same idea.  The closest you can
get right now is to do something like

   select * from parent_table t where t.tableoid = 'child1'::regclass

but this will fail to match grandchilden of child1.
I think a minimum expectation is that you could do
something like "where (t.*) is of (child1)", but
our existing code is nowhere near making that work.

Let's just rip it out and be done.  If anyone is ever
motivated to make it work per spec, they can resurrect
whatever seems useful from the git history.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Disable WAL logging to speed up data loading
Next
From: Joe Conway
Date:
Subject: Re: Should we document IS [NOT] OF?