Re: Schema variables - new implementation for Postgres 15
От | Julien Rouhaud |
---|---|
Тема | Re: Schema variables - new implementation for Postgres 15 |
Дата | |
Msg-id | 20220325041842.l2htaam54u4ie3gh@jrouhaud обсуждение исходный текст |
Ответ на | Re: Schema variables - new implementation for Postgres 15 (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
Hi, On Wed, Mar 23, 2022 at 09:58:59PM +0100, Pavel Stehule wrote: > > A bit more work seems to be needed for deparsing session variables: > > > > # create variable myvar text; > > CREATE VARIABLE > > > > # create view myview as select myvar; > > CREATE VIEW > > > > # \d+ myview > > View "public.myview" > > Column | Type | Collation | Nullable | Default | Storage | Description > > --------+------+-----------+----------+---------+----------+------------- > > myvar | text | | | | extended | > > View definition: > > SELECT myvar AS myvar; > > > > There shouldn't be an explicit alias I think. > > > > I check this issue, and I afraid so it is not fixable. The target list > entry related to session variable has not some magic value like ?column? > that can be used for check if tle->resname is implicit or explicit > > And in this time I cannot to use FigureColname because it doesn't work with > transformed nodes. More - the Param node can be nested in SubscriptingRef > or FieldSelect. It doesn't work perfectly now. See following example: > > create type xt as (a int, b int); > create view b as select (10, ((random()*100)::int)::xt).b; > \d+ b > SELECT (ROW(10, (random() * 100::double precision)::integer)::xt).b AS b; Fair enough. Since there is other code that already behaves the same I agree that it's better to not add special cases in ruleutils.c and have an explicit alias in the deparsed view, which isn't incorrect.
В списке pgsql-hackers по дате отправления: