Peter Eisentraut <peter_e@gmx.net> writes:
> I've been playing around with that a while ago in the hope that this would
> explain this table-as-datatype thing but several findings led me to
> believe that this is long dead, removed, rotten code:
There's an awful lot of code still there ;-). Undoubtedly it's
suffering from bit-rot, but I'm not sure the feature is as much
of a lost cause as you think.
> The function SetDefine in utils/adt/sets.c makes me think that a SET is
> more or less a stored procedure without arguments.
That squares with what I've been reading in the old Postgres papers;
they didn't call it a "set", but they definitely put a lot of emphasis
on the notion of a stored procedure that would generate a set of tuples
when called.
What I'm confused about at the moment is that there seem to be two
different facilities in the Postgres code that could be equated to
that concept. There is the "attisset" stuff, and then there is the
notion of a function that takes a relation as input and produces
another relation as output. The latter still sort of works --- there
are regression test cases that exercise it, and even though the
implementation has some fundamental shortcomings it is still useful.
This seems to be related to "attisset" but yet not be the same thing.
Like I said, I'm confused...
> That is, you would define some SET type in terms of a query from
> another table and then you could use predicates like `value in
> set'. The syntax for this must have gotten lost in the PostQUEL to SQL
> switch.
It's possible to invoke both facilities via the nested-dot notation.
If I understood which gets invoked when, I'd be a lot further along.
regards, tom lane
