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

From Wolfgang Walther
Subject Re: proposal: schema variables
Date
Msg-id 0e35aece-a138-4ee1-9bb8-92a4a55ff149@technowledgy.de
Whole thread Raw
In response to Re: proposal: schema variables  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal: schema variables
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




pgsql-hackers by date:

Previous
From: Kirill Reshke
Date:
Subject: Re: Index AM API cleanup
Next
From: Tom Lane
Date:
Subject: Re: Potential ABI breakage in upcoming minor releases