Re: proposal: schema variables - Mailing list pgsql-hackers

Pavel Stehule:
> (global (temp)) table can hold 0, 1 or more rows (and rows are always
> composite of 0..n fields). The variable holds a value of some type.
> Proposed session variables are like plpgsql variables (only with
> different scope). In Postgres there is a difference between a scalar
> variable and composite variable with one field.

I can store composite values in table columns, too. A table column can
either be scalar or composite in that sense.

So, maybe rephrase: Single-row, single-column (global (temp)) table =
variable. One "cell" of that table.

For me, the major difference between a variable and a table is, that the
table has 0...n rows and 0...m columns, while the variable has *exactly*
one in both cases, not 0 either.

I must put tables into FROM, why not those nice mini-tables called
variables as well? Because they are potentially scalar, you say!

But: I can already put functions returning scalar values into FROM:

   SELECT * FROM format('hello');

The function returns a plain string only.

I don't know. This just "fits" for me.

Or to put it differently: I don't really care whether I have to write
"(SELECT variable FROM variable)" instead of just "variable". I don't
want session variables for the syntax, I want session variables, because
they are **so much better** than custom GUCs.

Best,

Wolfgang