Re: Re: proposal: schema variables

hi.

you forgot change
<function>acldefault</function>
should add
'V' for <literal>SESSION VARIABLE</literal>


in doc/src/sgml/ddl.sgml
<sect1 id="ddl-session-variables">
maybe some examples (<programlisting>) of session variables being
shadowed would be great.

because doc/src/sgml/ref/create_variable.sgml said
  <note>
   <para>
    Session variables can be <quote>shadowed</quote> by other identifiers.
    For details, see <xref linkend="ddl-session-variables"/>.
   </para>
  </note>
If I click the link, then in ddl.sgml, there is also a bunch of text
saying that variable will be shadowed
in some situations, but there are no simple examples to demonstrate that.


"Create an date session variable <literal>var1</literal>:"
maybe it should be rephrased as
"Create a session variable <literal>var1</literal> as date data type?"
(i am not native english speaker)

-----------------------------------------------------------------------
--- a/src/include/nodes/primnodes.h
+++ b/src/include/nodes/primnodes.h
@@ -379,7 +379,8 @@ typedef struct Param
        Expr            xpr;
        ParamKind       paramkind;              /* kind of parameter.
See above */
        int                     paramid;                /* numeric ID
for parameter */
-       Oid                     paramtype;              /* pg_type OID
of parameter's datatype */
+       /* pg_type OID of parameter's datatype */
+       Oid                     paramtype
pg_node_attr(query_jumble_ignore);

I think we need the above to make
select v2;
select v1;
normalized as one query.
-----------------------------------------------------------------------
when we create a new table, we do something like this:
DefineRelation
heap_create_with_catalog
GetNewRelFileNumber
GetNewOidWithIndex

relation Oid uniqueness and variable uniqueness is the same thing.
If variable oid uniqueness problem ever reached,
at that moment, we should care more about relation oid uniqueness problem?

and in GetNewRelFileNumber, we have comments:
""
 * As with GetNewOidWithIndex(), there is some theoretical risk of a race
 * condition, but it doesn't seem worth worrying about.
"""
also comments in GetNewOidWithIndex
"""
 * Note that we are effectively assuming that the table has a relatively small
 * number of entries (much less than 2^32) and there aren't very long runs of
 * consecutive existing OIDs.  This is a mostly reasonable assumption for
 * system catalogs.
"""
that means pg_catalog.pg_variable.varcreate_lsn is not really necessary?
-----------------------------------------------------------------------
I think the latest patch for LET self assign ACL SELECT is not correct,
previously I also tried the same idea.

test demo.
CREATE TYPE vartest_t1 AS (a int, b int);
CREATE VARIABLE var1 AS vartest_t1;
CREATE ROLE regress_var_test_role;
GRANT UPDATE ON VARIABLE var1 TO regress_var_test_role;
GRANT select ON table tenk1 TO regress_var_test_role;
SET ROLE TO regress_var_test_role;

--both should fail
LET var1.a = var1.a + 10;
LET var1.a = (select * from (select count(*) from tenk1 where unique1
= var1.a + 10));
--------------------------------------------------------