Tom Lane writes:

> I have just been scanning some of the original Postgres papers
> (in an unsuccessful search to find out how one uses "set" attributes;
> anyone know?)

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:

* SET uses textin/textout

* no functions defined with SET arguments or return values,
pg_proc.proretset is false for all rows

* the only entry point for defining sets is in parser/parser.c, which is
fittingly marked #ifdef SETS_FIXED


The function SetDefine in utils/adt/sets.c makes me think that a SET is
more or less a stored procedure without arguments. 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. All in all there's not much to
rescue from there, I believe.


-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Tue, 16 May 2000 20:32:29 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
SET type (was Re: WAL versus Postgres)
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

Wed, 17 May 2000 01:49:15 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: SET type (was Re: WAL versus Postgres) 