Re: [HACKERS] Packages: Again - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] Packages: Again
Date
Msg-id CAFj8pRBBE_R+ng04eUUcsbtbv=xkTjrDGwAVp=hcF8njMp409A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Packages: Again  (Serge Rielau <serge@rielau.com>)
Responses Re: [HACKERS] Packages: Again  (Serge Rielau <serge@rielau.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal