Re: proposal: schema variables
От | Wolfgang Walther |
---|---|
Тема | Re: proposal: schema variables |
Дата | |
Msg-id | 0e35aece-a138-4ee1-9bb8-92a4a55ff149@technowledgy.de обсуждение исходный текст |
Ответ на | Re: proposal: schema variables (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: proposal: schema variables
|
Список | 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 по дате отправления: