Re: [HACKERS] proposal: schema variables

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] proposal: schema variables
Дата
Msg-id CAFj8pRBLTM6hetPRN1fKv-+MCYZKK9=Rk3n6xhKumt-vxE=E_Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] proposal: schema variables  (Arthur Zakirov <a.zakirov@postgrespro.ru>)
Ответы Re: [HACKERS] proposal: schema variables  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
Дерево обсуждения
Hi

I am sending rebased patch

2018-04-18 13:37 GMT+02:00 Arthur Zakirov <a.zakirov@postgrespro.ru>:
On Tue, Apr 17, 2018 at 06:28:19PM +0200, Pavel Stehule wrote:
> 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.

Understood. I haven't strong opinion here though. But I thought that
pg_class approach may limit extensibility of variables.

I didn't touch limit (I don't know if there will be some issue - still is far to upstream). This is technology, but workable, demo. I though so some users had a problem to imagine what is persistent variable in my view.

But almost all code and tests can be used for final version - only storage implementation is nothing more than workaround.
 

BTW:
- there is unitialized variable 'j' in pg_dump.c:15422
- in tab-complete.c:1268 initialization needs extra NULL before
  &Query_for_list_of_variables

I found it too today when I did rebase. But thank you for report.
 

Also I think makeRangeVarForTargetOfSchemaVariable() has non friendly
argument names 'field1', 'field2', 'field2'.

yes, I hadn't better names :(

In this routine I am doing diagnostic what semantic has sense for current values. the field1, field2 can be schema.variable or variable.field. So when I used semantic names: schema, varname, fieldname, then it was more messy (for me).

Regards

Pavel
 

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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: Built-in connection pooling
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS