MIME-Version: 1.0
In-Reply-To: <20180417141410.GA7917@zakirov.localdomain>
References: 
 <CAFj8pRDY+m9OOxfO10R7J0PAkCCauM-TweaTrdsrsLGMb1VbEQ@mail.gmail.com>
 <20180417141410.GA7917@zakirov.localdomain>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Tue, 17 Apr 2018 18:28:19 +0200
Message-ID: 
 <CAFj8pRD3RGW7zoHs2-4FgUKnV7TmHYbZiQYq1KS+KgwS3W30bQ@mail.gmail.com>
Subject: Re: [HACKERS] proposal: schema variables
To: Arthur Zakirov <a.zakirov@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="94eb2c0df0ece9558b056a0dd5b9"
Precedence: bulk

--94eb2c0df0ece9558b056a0dd5b9
Content-Type: text/plain; charset="UTF-8"

Hi

2018-04-17 16:14 GMT+02:00 Arthur Zakirov <a.zakirov@postgrespro.ru>:

> Hello Pavel,
>
> On Thu, Oct 26, 2017 at 09:21:24AM +0200, Pavel Stehule wrote:
> > I hope so this proposal is good enough and simple.
> >
> > Comments, notes?
>
> As I understood variables are stored in pg_class table. Did you consider
> storing variables in a special catalog table? It can be named as
> pg_variable.
>
> pg_variable table requires more code of course, but it would fix the
> issues:
> - pg_class has a lot attributes which are not related with variables,
>   and I think variables don't need many of them
> - in a future variables might want to have some additional attributes
>   which are not needed for relations, you can easily add them to
>   pg_variable
>
> What do you think?
>

I though about it, and I am inclined to prefer pg_class instead separate
tables.

It true, so there are lot of "unused" attributes for this purpose, but
there is lot of shared attributes, and lot of shared code. Semantically, I
see variables in family of sequences, tables, indexes, views. Now, it
shares code, and I hope in next steps more code can be shared -
constraints, triggers.

There are two objective arguments for using pg_class:

1. unique name in schema - it reduces risk of collisions
2. sharing lot of code

So in this case I don't see well benefits of separate table.

Regards

Pavel


>
> --
> Arthur Zakirov
> Postgres Professional: http://www.postgrespro.com
> Russian Postgres Company
>

--94eb2c0df0ece9558b056a0dd5b9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi<br><div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">2018-04-17 16:14 GMT+02:00 Arthur Zakirov <span dir=3D"ltr">&lt;=
<a href=3D"mailto:a.zakirov@postgrespro.ru" target=3D"_blank">a.zakirov@pos=
tgrespro.ru</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Pavel,<=
br>
<span class=3D""><br>
On Thu, Oct 26, 2017 at 09:21:24AM +0200, Pavel Stehule wrote:<br>
</span><span class=3D"">&gt; I hope so this proposal is good enough and sim=
ple.<br>
&gt; <br>
&gt; Comments, notes?<br>
<br>
</span>As I understood variables are stored in pg_class table. Did you cons=
ider<br>
storing variables in a special catalog table? It can be named as<br>
pg_variable.<br>
<br>
pg_variable table requires more code of course, but it would fix the issues=
:<br>
- pg_class has a lot attributes which are not related with variables,<br>
=C2=A0 and I think variables don&#39;t need many of them<br>
- in a future variables might want to have some additional attributes<br>
=C2=A0 which are not needed for relations, you can easily add them to<br>
=C2=A0 pg_variable<br>
<br>
What do you think?<br></blockquote><div><br></div><div>I though about it, a=
nd I am inclined to prefer pg_class instead separate tables. <br><br></div>=
<div>It true, so there are lot of &quot;unused&quot; attributes for this pu=
rpose, but there is lot of shared attributes, and lot of shared code. Seman=
tically, I see variables in family of sequences, tables, indexes, views. No=
w, it shares code, and I hope in next steps more code can be shared - const=
raints, triggers.<br><br></div><div>There are two objective arguments for u=
sing pg_class:<br><br></div><div>1. unique name in schema - it reduces risk=
 of collisions<br></div><div>2. sharing lot of code <br><br></div><div>So i=
n this case I don&#39;t see well benefits of separate table. <br><br></div>=
<div>Regards<br><br></div><div>Pavel<br></div><div><br>=C2=A0<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-- <br>
Arthur Zakirov<br>
Postgres Professional: <a href=3D"http://www.postgrespro.com" rel=3D"norefe=
rrer" target=3D"_blank">http://www.postgrespro.com</a><br>
Russian Postgres Company<br>
</font></span></blockquote></div><br></div></div></div>

--94eb2c0df0ece9558b056a0dd5b9--