Re: [HACKERS] Packages: Again

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] Packages: Again
Дата
Msg-id CAFj8pRBBE_R+ng04eUUcsbtbv=xkTjrDGwAVp=hcF8njMp409A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Packages: Again  (Serge Rielau <serge@rielau.com>)
Ответы Re: [HACKERS] Packages: Again  (Serge Rielau <serge@rielau.com>)
Список pgsql-hackers
Дерево обсуждения


2017-01-13 19:35 GMT+01:00 Serge Rielau <serge@rielau.com>:

> On Jan 13, 2017, at 10:23 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> I have not clean feeling from this - I am pretty sure so I am afraid schizophrenic  between MODULES, SCHEMAS. Nested schemas increase complexity of searching complexity and breaks a logic database.schema.object
Yes my proposal to nest schemata is “radical” and this community is not falling into that camp.
But there is nothing holy about database.schema.object.attribute

sure not - but lot of logic in SQL parser and PLpgSQL parser is based on it.
 
.
>
> Currently almost all in PostgreSQL PL design is primitive, but that means pretty simple too.
We are having > 30,000 functions with a total of millions of lines of code.

I understand so your working life is pretty hard :).
 

You are describing a self fulfilling prophecy here.
As long as the community codebase only caters to its existing users you will not see a change in the usage pattern of the base.

> It is hard to see a advantages of this proposal.

At least I tried :-)

I would be careful to translate a Oracle concept to PostgreSQL - The packages is Ada language concept - and there has clean role. In PL/SQL Oracle used packages like we used schema because Oracle has different concept of terms "database", of term "schema".  The packages in Postgres is more redundant than in Oracle. More the packages and related features are probably most difficult PL/SQL feature. Lot of people don't understand well - and it is not surprise for me, because PL/SQL is really hard mix of two very different worlds. 

I agree so there is some gap - there is nothing like package variables, package constants.  Can be nice to fill it.

With Postgres we should to think much more about other PL - there is not only PL/pgSQL. So any what we create should be available for any PL. Our PLpgSQL is based on total different technology design - so some benefits of sharing compiled code across databases has not too value in Postgres.

Maybe I am starting be old :) - I don't believe so stronger tools helps do things better - like Java - some applications are pretty good, some are the big heap of shit - and due strong language this heap is sometimes pretty big :)

If you need nested schemas, maybe you do some scary things, that should be better solved in application server. 

So I am not 100% against, but really I am sceptic if it is good idea. We don't design Postgres as platform for migration legacy Oracle code - on second hand we should not to create artificial breaks against this migrations.

Regards

Pavel





Serge




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal