Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

> > Thank you very much indeed for this careful reply, Pavel—and for the links > to the threads on the Hackers list. A great deal is now clarified for me. > You said “I am not native speaker, and my English is very poor”. You’re > far, far, too modest. I am a native English speaker. And I often see

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

> pavel.steh...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> Yes, I did read your “schema variables” post on your site “Pavel Stehule’s >> blog — Some notes about PostgreSQL”. It gives me a very good idea about what >> you have in mind. >> >> But as I’ve come to understand the term “Fu

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

> > From PostgreSQL's SQL perspective the session variables are common > database objects (contra SQL/PL where package variables are SQL/PL language > objects), and SQL disallows ambiguity. This is a little bit more complex > problem, because session variables can be used everywhere in Postgres (no

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

Hi Yes, I did read your “schema variables” post on your site “Pavel Stehule’s > blog — Some notes about PostgreSQL”. It gives me a very good idea about > what you have in mind. > > But as I’ve come to understand the term “Functional Spec”, this denotes a > formal deliverable that a product develop

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

> david.g.johns...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> update t set t.v = p.v where t.k = p.k; >> >> At run-time, p() terminates with an obscurely worded error: >> >> 42703: column "t" of relation "t" does not exist. > > "set t.v" is simply invalid SQL and the error has noth

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

On Wed, Dec 22, 2021 at 6:27 PM Bryn Llewellyn wrote: > > * update t set t.v = p.v where t.k = p.k;* > At run-time, p() terminates with an obscurely worded error: > > 42703: column "t" of relation "t" does not exist. > > "set t.v" is simply invalid SQL and the error has nothing with this discuss

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

> david.g.johns...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> Is this model not used for the PostgreSQL system? > > It is not. Basically we have an "Proposed Patches" tracker and they either > get committed, or they do no

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

> david.g.johns...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> Is this model not used for the PostgreSQL system? > > It is not. Basically we have an "Proposed Patches" tracker and they either > get committed, or they do not. Once committed, new features become available > at the nex

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

On Wed, Dec 22, 2021 at 1:54 PM Bryn Llewellyn wrote: > > Is this model not used for the PostgreSQL system? > It is not. Basically we have an "Proposed Patches" tracker and they either get committed, or they do not. Once committed, new features become available at the next annual release. >

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

> pavel.steh...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >>> pavel.steh...@gmail.com wrote: >>> b...@yugabyte.com wrote: I’m still hoping that I might get some pointers to whitepapers or blog posts that expand on those bullets that I quoted from the PG doc: «Inste

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

út 21. 12. 2021 v 19:58 odesílatel Michael Lewis napsal: > On Tue, Dec 21, 2021 at 11:50 AM Pavel Stehule > wrote: > >> I wrote about it. Did you read this article? >> >> https://okbob.blogspot.com/2018/02/schema-variables.html >> >> The goals of this project: >> >>- fast non transactional n

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

On Tue, Dec 21, 2021 at 11:50 AM Pavel Stehule wrote: > I wrote about it. Did you read this article? > > https://okbob.blogspot.com/2018/02/schema-variables.html > > The goals of this project: > >- fast non transactional non persistent (session based) storage, > > Would there be statistics th

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

út 21. 12. 2021 v 19:28 odesílatel Bryn Llewellyn napsal: > *pavel.steh...@gmail.com wrote:* > > > *b...@yugabyte.com wrote:* > > I’m still hoping that I might get some pointers to whitepapers or blog > posts that expand on those bullets that I quoted from the PG doc: «Instead > of packages, us

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

> pavel.steh...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> I’m still hoping that I might get some pointers to whitepapers or blog posts >> that expand on those bullets that I quoted from the PG doc: «Instead of >> packages, use schemas to organize your functions into groups.» and «Si

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

Hi > I’m still hoping that I might get some pointers to whitepapers or blog > posts that expand on those bullets that I quoted from the PG doc: «Instead > of packages, use schemas to organize your functions into groups.» and > «Since there are no packages, there are no package-level variables eit

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

b...@yugabyte.com wrote: > >> p...@bowt.ie wrote: >> >>> b...@yugabyte.com wrote: >>> >>> Modular design recommends exposing functionality through a purpose oriented >>> interface and hiding all implementation details from the API’s user. A >>>

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

> p...@bowt.ie wrote: > >> b...@yugabyte.com wrote: >> >> Modular design recommends exposing functionality through a purpose oriented >> interface and hiding all implementation details from the API’s user. A >> package achieves this with declarative syntax via the spec/body separation. >> The

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

On Fri, Dec 17, 2021 at 11:43 AM Bryn Llewellyn wrote: > Modular design recommends exposing functionality through a purpose oriented > interface and hiding all implementation details from the API’s user. A > package achieves this with declarative syntax via the spec/body separation. > The body

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

laurenz.a...@cybertec.at wrote: > >> b...@yugabyte.com wrote: >> >> The advantages are self-evident to these programmers… > > I am not trying to belittle this, but when you are used to system A and start > working with system B you always miss some features of A, until you get to > know B bett

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

On Thu, 2021-12-16 at 11:22 -0800, Bryn Llewellyn wrote: > The advantages are self-evident to these programmers I am not trying to belittle this, but when you are used to system A and start working with system B you always miss some features of A, until you get to know B better and figure out how

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

Hi pá 17. 12. 2021 v 3:39 odesílatel Mladen Gogala napsal: > On 12/16/21 16:48, Pavel Stehule wrote: > > I don't think Postgres needs packages - this is a redundant concept in > > Postgres, when Postgres has schemas (different from Oracle's schemas) > > and extensions. > > > Yes, ORAFCE uses sch

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

On Thu, Dec 16, 2021 at 6:39 PM Mladen Gogala wrote: > I am very well aware of the animosity toward the Oracle community and > the reasons for that animosity. Oracle wiped the floor with the > predecessor of Postgres, the database called "Ingres". Sandra Kurtzig, > the Ingres CEO at the the time,

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

On 12/16/21 16:48, Pavel Stehule wrote: I don't think Postgres needs packages - this is a redundant concept in Postgres, when Postgres has schemas (different from Oracle's schemas) and extensions. Yes, ORAFCE uses schemas as the package names. However, one very practical thing is missing: ses

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

čt 16. 12. 2021 v 20:22 odesílatel Bryn Llewellyn napsal: > Folks who develop applications for Oracle Database have had the features > that the subject line of this email lists since the arrival of PL/SQL in > the early nineties. The advantages are self-evident to these programmers; > and their l

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

On Thu, Dec 16, 2021 at 11:22 AM Bryn Llewellyn wrote: > The advantages are self-evident to these programmers; and their lack comes as > a shocking disappointment when they start to write application code for > PostgreSQL*. The absence of packages and inner subprograms is huge. Why are those th

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

On 12/16/21 12:36, Bryn Llewellyn wrote: // /adrian.kla...@aklaver.com wrote: / Not following. To be exposed they have to exist and that is not the case in the community Postgres. The relevant question would seem to be, how do I get these features built?

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

> adrian.kla...@aklaver.com wrote: > >> b...@yugabyte.com wrote: >> >> Folks who develop applications for Oracle Database have had the features >> that the subject line of this email lists since the arrival of PL/SQL in the >> early nineties. The advantages are self-evident to these programmers

Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL

On 12/16/21 11:22, Bryn Llewellyn wrote: Folks who develop applications for Oracle Database have had the features that the subject line of this email lists since the arrival of PL/SQL in the early nineties. The advantages are self-evident to these programmers; and their lack comes as a shockin