Re: [HACKERS] PL/pgSQL 2

On 10/7/14, 1:08 PM, Rodolfo Campero wrote: If it were possible to mark a function as "private for its extension" that would be awesome (the opposite would work too, i.e. a way to specify a public API, meaning the rest is private). For big extensions it's not clear which functions can be used

Re: [HACKERS] PL/pgSQL 2

On Tue, Oct 7, 2014 at 12:42 PM, Steven Lembark wrote: > On Mon, 1 Sep 2014 15:19:41 +0200 > Joel Jacobson wrote: > >> The fatal problems with Python3 and Perl6 was the inability to mix >> code between Python2/3 and Perl5/6. >> We don't have that problem with pl-languages in postgres, so please >

Re: [HACKERS] PL/pgSQL 2

2014-09-04 18:29 GMT-03:00 Robert Haas : > On Thu, Sep 4, 2014 at 2:31 PM, Josh Berkus wrote: > > Sadly, what's prevented us from having "packages" already has been the > > insistence of potential feature sponsors that they work *exactly* like > > PL/SQL's packages, which is incompatible with Pos

Re: [HACKERS] PL/pgSQL 2

On Mon, 1 Sep 2014 15:19:41 +0200 Joel Jacobson wrote: > The fatal problems with Python3 and Perl6 was the inability to mix > code between Python2/3 and Perl5/6. > We don't have that problem with pl-languages in postgres, so please > don't make that comparison, as it's incorrect. Actually Perl6

Re: [HACKERS] PL/pgSQL 2

> Python2 -> Python3 would've been a lot less painful if you could mark, > on a module-by-module basis, whether a module was python2 or python3 > code. It wasn't very practical for Python because python code can reach > deep into the guts of unrelated objects discovered at runtime - it can > add/

Re: [HACKERS] PL/pgSQL 2

On Mon, 01 Sep 2014 12:00:48 +0200 Marko Tiikkaja wrote: > create a new language. There are enough problems with SQL in general, enough alternatives proposed over time that it might be worth coming up with something that Just Works. -- Steven Lembark

Re: [HACKERS] PL/pgSQL 2

On 04/09/14 18:02, Craig Ringer wrote: On 09/04/2014 06:48 AM, Joshua D. Drake wrote: On 09/03/2014 11:48 AM, Robert Haas wrote: Anyway, to get back around to the topic of PL/SQL compatibility specifically, if you care about that issue, pick one thing that exists in PL/SQL but not in PL/pgsql

Re: [HACKERS] PL/pgSQL 2

On 03/09/14 20:48, Robert Haas wrote: On Tue, Sep 2, 2014 at 5:47 PM, Álvaro Hernández Tortosa wrote: Yeah, we differ there. I think having an Oracle compatibility layer in PostgreSQL would be the-next-big-thing we could have. Oracle is has orders of magnitude bigger user base than postgr

Re: [HACKERS] PL/pgSQL 2

On Fri, Sep 5, 2014 at 6:18 PM, Andrew Dunstan wrote: > > On 09/05/2014 12:37 PM, Merlin Moncure wrote: >> >> On Thu, Sep 4, 2014 at 6:40 PM, Florian Pflug wrote: Cost of hidden IO cast is negative too. If we can change it, then we can increase a sped. >>> >>> But the whole power o

Re: [HACKERS] PL/pgSQL 2

On 09/06/2014 12:47 PM, David G Johnston wrote: ​If the language, and the system as a whole, was only used by perfectionists that do not make errors - and with perfectly clean data - this adherence to purity would be acceptable. But the real world is not that clean and so enhancing the language

Re: [HACKERS] PL/pgSQL 2

On Sat, Sep 6, 2014 at 12:38 PM, Jan Wieck-3 [via PostgreSQL] < ml-node+s1045698n5818047...@n5.nabble.com> wrote: > On 09/06/2014 12:33 PM, Marko Tiikkaja wrote: > > > On 2014-09-06 6:31 PM, Jan Wieck wrote: > >> On 09/06/2014 12:17 PM, Marko Tiikkaja wrote: > >>> OK, fine. But that's not what I

Re: [HACKERS] PL/pgSQL 2

On 09/06/2014 12:33 PM, Marko Tiikkaja wrote: On 2014-09-06 6:31 PM, Jan Wieck wrote: On 09/06/2014 12:17 PM, Marko Tiikkaja wrote: OK, fine. But that's not what I suggested on the wiki page, and is also not what I'm arguing for here right now. What the message you referred to was about was t

Re: [HACKERS] PL/pgSQL 2

On 2014-09-06 6:31 PM, Jan Wieck wrote: On 09/06/2014 12:17 PM, Marko Tiikkaja wrote: OK, fine. But that's not what I suggested on the wiki page, and is also not what I'm arguing for here right now. What the message you referred to was about was the condescending attitude where we were told to

Re: [HACKERS] PL/pgSQL 2

On 09/06/2014 12:17 PM, Marko Tiikkaja wrote: OK, fine. But that's not what I suggested on the wiki page, and is also not what I'm arguing for here right now. What the message you referred to was about was the condescending attitude where we were told to "think in terms of sets" (paraphrased),

Re: [HACKERS] PL/pgSQL 2

On 2014-09-06 6:06 PM, Jan Wieck wrote: You can dismiss what we're doing by saying that it doesn't follow the best practices or we just want an interface for a key-value store or whatever. And yes, to some extent, a simple interface for a key-value store would come in handy. But we still have t

Re: [HACKERS] PL/pgSQL 2

On 09/05/2014 10:32 PM, Marko Tiikkaja wrote: On 2014-09-02 8:52 PM, Kevin Grittner wrote: Marko Tiikkaja wrote: Sounds like in this case you'd only use set-oriented programming at the end of the transaction, no? I guess -- more properly I would say "in the final database transaction for th

Re: [HACKERS] PL/pgSQL 2

On 2014-09-02 8:52 PM, Kevin Grittner wrote: Marko Tiikkaja wrote: Sounds like in this case you'd only use set-oriented programming at the end of the transaction, no? I guess -- more properly I would say "in the final database transaction for that financial transaction." Yes, I should have

Re: [HACKERS] PL/pgSQL 2

On 09/05/2014 12:37 PM, Merlin Moncure wrote: On Thu, Sep 4, 2014 at 6:40 PM, Florian Pflug wrote: Cost of hidden IO cast is negative too. If we can change it, then we can increase a sped. But the whole power of PL/pgSQL comes from the fact that it allows you to use the full set of postgres d

Re: [HACKERS] PL/pgSQL 2

On Thu, Sep 4, 2014 at 6:40 PM, Florian Pflug wrote: >> Cost of hidden IO cast is negative too. If we can change it, then we can >> increase a sped. > > But the whole power of PL/pgSQL comes from the fact that it allows you to > use the full set of postgres data types and operatores, and that it s

Re: [HACKERS] PL/pgSQL 2

On Sep4, 2014, at 20:50 , Pavel Stehule wrote: > 2014-09-04 20:31 GMT+02:00 Josh Berkus : > * The ability to "compile" functions/procedures for faster execution. > > This point is more complex, because bottleneck is not in plpgsql - it is > terrible fast against noncompiled pcode interpreted PL/S

Re: [HACKERS] PL/pgSQL 2

On Thu, Sep 4, 2014 at 2:31 PM, Josh Berkus wrote: > Sadly, what's prevented us from having "packages" already has been the > insistence of potential feature sponsors that they work *exactly* like > PL/SQL's packages, which is incompatible with Postgres namespacing. > Also, we'd want any "package"

Re: [HACKERS] PL/pgSQL 2

* Robert Haas (robertmh...@gmail.com) wrote: > Second, if you did manage to develop something which was significantly > more compatible with Oracle than PostgreSQL or PL/pgsql is today, > you'd probably find that the community wouldn't accept it. Agreed. Moving PostgreSQL forward is what the comm

Re: [HACKERS] PL/pgSQL 2

2014-09-04 20:31 GMT+02:00 Josh Berkus : > On 09/04/2014 09:02 AM, Craig Ringer wrote: > > There are a few things I would like to see, like secure session > > variables in PL/PgSQL. Mostly, though, I think talk of "Oracle > > compatibility" seems to be something that comes up before the speaker >

Re: [HACKERS] PL/pgSQL 2

On 09/04/2014 09:02 AM, Craig Ringer wrote: > There are a few things I would like to see, like secure session > variables in PL/PgSQL. Mostly, though, I think talk of "Oracle > compatibility" seems to be something that comes up before the speaker > has really understood what that would mean, and th

Re: [HACKERS] PL/pgSQL 2

Hi Craig 2014-09-04 17:54 GMT+02:00 Craig Ringer : > On 09/04/2014 02:48 AM, Robert Haas wrote: > > To take another example, I've been complaining about the fact > > that PostgreSQL 8.3+ requires far more typecasts in stored procedures > > than any other database I'm aware of for years, probably

Re: [HACKERS] PL/pgSQL 2

On 09/04/2014 06:48 AM, Joshua D. Drake wrote: > > On 09/03/2014 11:48 AM, Robert Haas wrote: > >> Anyway, to get back around to the topic of PL/SQL compatibility >> specifically, if you care about that issue, pick one thing that exists >> in PL/SQL but not in PL/pgsql and try to do something abo

Re: [HACKERS] PL/pgSQL 2

On 9/4/14 5:54 PM, Craig Ringer wrote: On 09/04/2014 02:48 AM, Robert Haas wrote: To take another example, I've been complaining about the fact that PostgreSQL 8.3+ requires far more typecasts in stored procedures than any other database I'm aware of for years, probably since before I joined Ent

Re: [HACKERS] PL/pgSQL 2

On 09/04/2014 02:48 AM, Robert Haas wrote: > To take another example, I've been complaining about the fact > that PostgreSQL 8.3+ requires far more typecasts in stored procedures > than any other database I'm aware of for years, probably since before > I joined EnterpriseDB. +10 This still drives

Re: [HACKERS] PL/pgSQL 2

> On 4 sep 2014, at 15:09, Shaun Thomas wrote: > >> On 09/01/2014 04:04 AM, Joel Jacobson wrote: >> >> + Make UPDATE/INSERT/DELETE throw error if they didnt' modify exactly 1 >> row, as that's the most common use-case, and provide alternative syntax >> to modify multiple or zero rows. > > What? No

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 04:04 AM, Joel Jacobson wrote: + Make UPDATE/INSERT/DELETE throw error if they didnt' modify exactly 1 row, as that's the most common use-case, and provide alternative syntax to modify multiple or zero rows. What? No. The whole point of SQL is that it's set-based and can modify

Re: [HACKERS] PL/pgSQL 2

On 09/03/2014 11:48 AM, Robert Haas wrote: Anyway, to get back around to the topic of PL/SQL compatibility specifically, if you care about that issue, pick one thing that exists in PL/SQL but not in PL/pgsql and try to do something about it. Maybe it'll be something that EnterpiseDB has alread

Re: [HACKERS] PL/pgSQL 2

2014-09-03 21:01 GMT+02:00 David G Johnston : > This is more of an SQL request the pl/pgsql but is/has there been thought > to > adding the ternary if/then opeator? Something like: > > boolean_exp ?> val_if_true : val_if_false > > using "?" by itself would be OK but not ideal - and the addition o

Re: [HACKERS] PL/pgSQL 2

This is more of an SQL request the pl/pgsql but is/has there been thought to adding the ternary if/then opeator? Something like: boolean_exp ?> val_if_true : val_if_false using "?" by itself would be OK but not ideal - and the addition of the ">" doesn't seem hateful... Sorry if this is deemed

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 5:47 PM, Álvaro Hernández Tortosa wrote: > Yeah, we differ there. I think having an Oracle compatibility layer in > PostgreSQL would be the-next-big-thing we could have. Oracle is has orders > of magnitude bigger user base than postgres has; and having the ability to > a

Re: [HACKERS] PL/pgSQL 2

On 03/09/14 15:24, Joshua D. Drake wrote: On 09/02/2014 04:01 PM, Álvaro Hernández Tortosa wrote: It's not copying. It's easying a path for others to migrate and come to Postgres. I'm interested why you are more interested in MSSQL. My reasons for being interested in Oracle are: -

Re: [HACKERS] PL/pgSQL 2

2014-09-03 17:05 GMT+02:00 Bruce Momjian : > On Wed, Sep 3, 2014 at 07:54:09AM +0200, Pavel Stehule wrote: > > I am not against to improve a PL/pgSQL. And I repeat, what can be done > and can > > be done early: > > > > a) ASSERT clause -- with some other modification to allow better static > anal

Re: [HACKERS] PL/pgSQL 2

On 9/3/14 5:05 PM, Bruce Momjian wrote: On Wed, Sep 3, 2014 at 07:54:09AM +0200, Pavel Stehule wrote: I am not against to improve a PL/pgSQL. And I repeat, what can be done and can be done early: a) ASSERT clause -- with some other modification to allow better static analyze of DML statements,

Re: [HACKERS] PL/pgSQL 2

On Wed, Sep 3, 2014 at 07:54:09AM +0200, Pavel Stehule wrote: > I am not against to improve a PL/pgSQL. And I repeat, what can be done and can > be done early: > > a) ASSERT clause -- with some other modification to allow better static > analyze > of DML statements, and enforces checks in runtim

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 08:46:36PM -0400, Christopher Browne wrote: > 3.  Is there anything to be learned from Tutorial D?  That is, Date & Darwen's > would-be alternative to SQL of their Third Manifesto? What would a set-oriented-language PL look like, such as APL? I guess Perl has arrays, so it

Re: [HACKERS] PL/pgSQL 2

On 09/03/2014 03:14 AM, Joel Jacobson wrote: I'm in favour of Tom's idea. To merely make the plpgsql2 "language" a way of explicitly saying you want a specific exact combination of features/beaviour/settings which we can implemented in plpgsql's existing codebase. Since it was about 100 posts si

Re: [HACKERS] PL/pgSQL 2

On Wed, Sep 3, 2014 at 3:17 PM, Joshua D. Drake wrote: > Well, I don't think PostgreSQL needs its own PL. I mean we already have > several (what other database has pl/javascript or pl/python?) PostgreSQL already *have* it's own PL, it's called PL/pgSQL. > Besides, the idea of this community tryi

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 04:01 PM, Álvaro Hernández Tortosa wrote: It's not copying. It's easying a path for others to migrate and come to Postgres. I'm interested why you are more interested in MSSQL. My reasons for being interested in Oracle are: - It has more users (biggest and above all, t

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 03:50 PM, Jan Wieck wrote: PL/pgSQL's syntax was modelled to look like PL/SQL. Which is a Ada/COBOL lookalike. Instead of trying to mimic what it was or a T-SQL thing instead ... maybe it is time to come up with a true PostgreSQL specific PL for a change? Just for the sake of be

Re: [HACKERS] PL/pgSQL 2

On Wed, Sep 3, 2014 at 10:07 AM, Pavel Stehule wrote: > When you use name plpgsql2 you say, so plpgsql2 is successor plpgsql. It is > very hard to accept it. So any other name is not problem for me - like > plpgsql-safe-subset or something else plpgsql2 *is* the successor of plpgsql, that's why

Re: [HACKERS] PL/pgSQL 2

2014-09-03 9:14 GMT+02:00 Joel Jacobson : > On Wed, Sep 3, 2014 at 7:54 AM, Pavel Stehule > wrote: > > I am not against to improve a PL/pgSQL. And I repeat, what can be done > and > > can be done early: > > > > a) ASSERT clause -- with some other modification to allow better static > > analyze of

Re: [HACKERS] PL/pgSQL 2

On Wed, Sep 3, 2014 at 7:54 AM, Pavel Stehule wrote: > I am not against to improve a PL/pgSQL. And I repeat, what can be done and > can be done early: > > a) ASSERT clause -- with some other modification to allow better static > analyze of DML statements, and enforces checks in runtime. > > b) #op

Re: [HACKERS] PL/pgSQL 2

On 3 September 2014 01:08, Jan Wieck wrote: > On 09/02/2014 06:56 PM, Andrew Dunstan wrote: > >> People are free to do what they want, but to my mind that would be a >> massive waste of resources, and probably imposing a substantial extra >> maintenance burden on the core committers. >> > > I hea

Re: [HACKERS] PL/pgSQL 2

2014-09-03 7:23 GMT+02:00 Joel Jacobson : > On Wed, Sep 3, 2014 at 7:17 AM, Pavel Stehule > wrote: > > yes, but there is minimal agreement of direction of movement. I am not > alone > > who are thinking so your proposal is not good for general usage. > > Minimal agreement? That's not true. The ot

Re: [HACKERS] PL/pgSQL 2

On Wed, Sep 3, 2014 at 7:17 AM, Pavel Stehule wrote: > yes, but there is minimal agreement of direction of movement. I am not alone > who are thinking so your proposal is not good for general usage. Minimal agreement? That's not true. The other group of users have been discussing a completely new

Re: [HACKERS] PL/pgSQL 2

On Wed, Sep 3, 2014 at 2:46 AM, Christopher Browne wrote: > The notion of hacking features onto plpgsql2 that mostly seem like SQL > enhancements is a waste of time. New versions of languages who change too much in a new version are doomed to fail. There are many such examples in history. Complet

Re: [HACKERS] PL/pgSQL 2

2014-09-03 7:07 GMT+02:00 Joel Jacobson : > On Wed, Sep 3, 2014 at 12:19 AM, Josh Berkus wrote: > > On 09/01/2014 02:04 AM, Joel Jacobson wrote: > >> Please share your wish list of things you would want in plpgsql2 which > >> are not possible to implement in plpgsql because they could possibly >

Re: [HACKERS] PL/pgSQL 2

On Wed, Sep 3, 2014 at 12:19 AM, Josh Berkus wrote: > On 09/01/2014 02:04 AM, Joel Jacobson wrote: >> Please share your wish list of things you would want in plpgsql2 which >> are not possible to implement in plpgsql because they could possibly >> break compatibility. > > Well, if I were designing

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 7:08 PM, Jan Wieck wrote: > On 09/02/2014 06:56 PM, Andrew Dunstan wrote: > >> People are free to do what they want, but to my mind that would be a >> massive waste of resources, and probably imposing a substantial extra >> maintenance burden on the core committers. >> > >

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 06:56 PM, Andrew Dunstan wrote: People are free to do what they want, but to my mind that would be a massive waste of resources, and probably imposing a substantial extra maintenance burden on the core committers. I hear you and agree to some degree. But at the same time I rememb

Re: [HACKERS] PL/pgSQL 2

On 03/09/14 00:41, Joshua D. Drake wrote: On 09/02/2014 02:47 PM, Álvaro Hernández Tortosa wrote: Yeah, we differ there. I think having an Oracle compatibility layer in PostgreSQL would be the-next-big-thing we could have. Oracle is has orders of magnitude bigger user base than postgres

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 06:50 PM, Jan Wieck wrote: On 09/02/2014 06:41 PM, Joshua D. Drake wrote: On 09/02/2014 02:47 PM, Álvaro Hernández Tortosa wrote: Yeah, we differ there. I think having an Oracle compatibility layer in PostgreSQL would be the-next-big-thing we could have. Oracle is has ord

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 06:41 PM, Joshua D. Drake wrote: On 09/02/2014 02:47 PM, Álvaro Hernández Tortosa wrote: Yeah, we differ there. I think having an Oracle compatibility layer in PostgreSQL would be the-next-big-thing we could have. Oracle is has orders of magnitude bigger user base than postg

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 03:19 PM, Josh Berkus wrote: On 09/01/2014 02:04 AM, Joel Jacobson wrote: Please share your wish list of things you would want in plpgsql2 which are not possible to implement in plpgsql because they could possibly break compatibility. Well, if I were designing a new procedural

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 02:47 PM, Álvaro Hernández Tortosa wrote: Yeah, we differ there. I think having an Oracle compatibility layer in PostgreSQL would be the-next-big-thing we could have. Oracle is has orders of magnitude bigger user base than postgres has; and having the ability to attract them

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 03:19 PM, Josh Berkus wrote: > Well, if I were designing a new procedural SQL extension language, I > wouldn't base it on the bastard child of ADA and SQL89. I would come up Ada, that is. One is a programming language, the other is the bane of architects. -- Josh Berkus PostgreSQ

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 02:04 AM, Joel Jacobson wrote: > Please share your wish list of things you would want in plpgsql2 which > are not possible to implement in plpgsql because they could possibly > break compatibility. Well, if I were designing a new procedural SQL extension language, I wouldn't base it

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 04:16 PM, Andres Freund wrote: On 2014-09-02 19:06:02 +0200, Joel Jacobson wrote: But what do you think about, STRICT UPDATE ...? I quite dislike it. An UPDATE isn't less 'strict' (whatever that means) if updates more than one row. There's some sense in the way it's used for INTO

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 23:34, Joshua D. Drake wrote: On 09/02/2014 02:11 PM, David Johnston wrote: On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake mailto:j...@commandprompt.com>>wrote: On 09/02/2014 09:48 AM, Bruce Momjian wrote: As a case in point, EDB have spent quite a few man-years

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 09:32 AM, Joel Jacobson wrote: I think it's much better to make it the default behaviour in plpgsql2 than to add a new syntax to plpgsql, because then we don't have to argue what to call the keyword or where to put it. This should in NO CASE be any new syntax to plpgsql or plpgsq

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 02:11 PM, David Johnston wrote: On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake mailto:j...@commandprompt.com>>wrote: On 09/02/2014 09:48 AM, Bruce Momjian wrote: As a case in point, EDB have spent quite a few man-years on their Oracle com

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 23:11, David Johnston wrote: On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake >wrote: On 09/02/2014 09:48 AM, Bruce Momjian wrote: As a case in point, EDB have spent quite a few man-years on their Oracle compati

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 10:41 AM, Joel Jacobson wrote: On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer wrote: Well, the idiom: EXECUTE format("SELECT %I FROM %I WHERE $1", col, tbl) USING val; is not lovely. It works, but it's clumsy. This is exactly why we need a new language. All the clumsy stuff we

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 12:20 PM, Joel Jacobson wrote: On Tue, Sep 2, 2014 at 6:09 PM, Kevin Grittner wrote: Joel Jacobson wrote: Sorry for being unclear, I didn't mean to suggest the main concern is updating *all* rows. The main concern is when you have a rather complex UPDATE WHERE clause, aiming to

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 10:27 PM, Merlin Moncure wrote: > What is the reasoning for breaking compatibiilty? Why not improve the > language that's there? Because many suggested improvement are not possible without breaking compatibility, at least in theory. See previous posts in the thread. > whe

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 09:06 PM, Andrew Dunstan wrote: On 09/01/2014 08:09 PM, Neil Tiffin wrote: The docs also tell you how to avoid having to do this, using dollar quoting. That should be enough alone to suggest postgreSQL start working on a modern, in core, fast, fully supported language. Of cou

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 10:16 PM, Andres Freund wrote: > On 2014-09-02 19:06:02 +0200, Joel Jacobson wrote: >> But what do you think about, >> STRICT UPDATE ...? > > I quite dislike it. An UPDATE isn't less 'strict' (whatever that means) > if updates more than one row. There's some sense in the way

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake wrote: > > On 09/02/2014 09:48 AM, Bruce Momjian wrote: > > As a case in point, EDB have spent quite a few man-years on their Oracle >>> compatibility layer; and it's still not a terribly exact match, according >>> to my colleagues who have looked

Re: [HACKERS] PL/pgSQL 2

Without having read the entire thread ... On 09/01/2014 05:04 AM, Joel Jacobson wrote: From the top of my head, these are Things I personally would want to see in plpgsql2: + Make UPDATE/INSERT/DELETE throw error if they didnt' modify exactly 1 row, as that's the most common use-case, and provi

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 09:48 AM, Bruce Momjian wrote: As a case in point, EDB have spent quite a few man-years on their Oracle compatibility layer; and it's still not a terribly exact match, according to my colleagues who have looked at it. So that is a tarbaby I don't personally care to touch ... even

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 4:04 AM, Joel Jacobson wrote: > Hi, > > For those of you who use PL/pgSQL every day, I'm quite certain you all feel > there are a number of things you would like to change in the language, but > realize it cannot be achieved without possibly breaking compatibility, at > leas

Re: [HACKERS] PL/pgSQL 2

On 2014-09-02 19:06:02 +0200, Joel Jacobson wrote: > But what do you think about, > STRICT UPDATE ...? I quite dislike it. An UPDATE isn't less 'strict' (whatever that means) if updates more than one row. There's some sense in the way it's used for INTO because it's referring to the INTO. And it's

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 07:06:02PM +0200, Joel Jacobson wrote: > On Tue, Sep 2, 2014 at 7:01 PM, Bruce Momjian wrote: > > On Tue, Sep 2, 2014 at 06:57:42PM +0200, Joel Jacobson wrote: > >> On Tue, Sep 2, 2014 at 6:45 PM, Bruce Momjian wrote: > >> > SINGLETON UPDATE ...? > >> > >> Does it come wi

Re: [HACKERS] PL/pgSQL 2

Marko Tiikkaja wrote: > Sounds like in this case you'd only use set-oriented programming > at the end of the transaction, no? I guess -- more properly I would say "in the final database transaction for that financial transaction."  And no, that never made me wish that plpgsql functions defaulted

Re: [HACKERS] PL/pgSQL 2

On 2014-09-02 19:33, Kevin Grittner wrote: Marko Tiikkaja wrote: Well, just off the top of my head a normal function invocation could be: one worker working on a single "order" started by a single end user to transfer money from one account to another. And we have *a lot* of code like this

Re: [HACKERS] PL/pgSQL 2

2014-09-02 15:58 GMT+02:00 Marko Tiikkaja : > On 9/2/14 3:52 PM, Joel Jacobson wrote: > >> On Tue, Sep 2, 2014 at 3:41 PM, Heikki Linnakangas >> wrote: >> >>> On 09/02/2014 04:32 PM, Joel Jacobson wrote: >>> I think it's much better to make it the default behaviour in plpgsql2 than to a

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 07:51 PM, Marko Tiikkaja wrote: On 9/2/14 6:03 PM, Heikki Linnakangas wrote: Marko posted a patch to add assertions to PL/pgSQL last year, see http://www.postgresql.org/message-id/5234af3f.4000...@joh.to. It was a long thread, but in the end I think everyone was more or less OK wit

Re: [HACKERS] PL/pgSQL 2

Marko Tiikkaja wrote: > Well, just off the top of my head a normal function invocation could be: > one worker working on a single "order" started by a single end user to > transfer money from one account to another.  And we have *a lot* of code > like this where there isn't a way to write the cod

Re: [HACKERS] PL/pgSQL 2

On 9/2/14 6:31 PM, Heikki Linnakangas wrote: On 09/02/2014 07:12 PM, Joel Jacobson wrote: For me, updating a row, is like setting a variable in a normal language. No normal language would require two rows to set a variable. It would be like having to do: my $var = 10; die unless $var =

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 7:01 PM, Bruce Momjian wrote: > On Tue, Sep 2, 2014 at 06:57:42PM +0200, Joel Jacobson wrote: >> On Tue, Sep 2, 2014 at 6:45 PM, Bruce Momjian wrote: >> > SINGLETON UPDATE ...? >> >> Does it come with built-in spell check? :-) It's a bit long to write. >> I like STRICT, th

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 06:57:42PM +0200, Joel Jacobson wrote: > On Tue, Sep 2, 2014 at 6:45 PM, Bruce Momjian wrote: > > SINGLETON UPDATE ...? > > Does it come with built-in spell check? :-) It's a bit long to write. > I like STRICT, that maps good to what we already have with SELECT ... > INTO

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 6:45 PM, Bruce Momjian wrote: > SINGLETON UPDATE ...? Does it come with built-in spell check? :-) It's a bit long to write. I like STRICT, that maps good to what we already have with SELECT ... INTO STRICT. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 6:31 PM, Heikki Linnakangas wrote: > I don't think most applications are like that. See Kevin's comments about > doing things in a set-oriented way instead of row-by-row. I know I've > changed several procedures from the row-oriented style, looping over rows > with a FOR loo

Re: [HACKERS] PL/pgSQL 2

On 9/2/14 6:03 PM, Heikki Linnakangas wrote: Marko posted a patch to add assertions to PL/pgSQL last year, see http://www.postgresql.org/message-id/5234af3f.4000...@joh.to. It was a long thread, but in the end I think everyone was more or less OK with the syntax "ASSERT ;". I also think that synt

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 12:40:14AM -0400, Tom Lane wrote: > Craig Ringer writes: > > If someone came up with a convincing PL/SQL compatibility layer then > > it'd be worth considering adopting - when it was ready. But of course, > > anyone who does the work for that is quite likely to want to sell

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 04:24:11PM +0200, Andres Freund wrote: > On 2014-09-02 10:21:50 -0400, Tom Lane wrote: > > Marko Tiikkaja writes: > > > For example: > > > > > UPDATE foo WHERE bar = 1; -- must affect exactly one row > > > PERFORM UPDATE foo WHERE bar = 1; -- can affect any number of rows

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 18:33, Hannu Krosing wrote: On 09/02/2014 06:27 PM, Joel Jacobson wrote: On Tue, Sep 2, 2014 at 6:11 PM, Álvaro Hernández Tortosa wrote: We are definitely worse. This is the problem, we only look to our own belly bottom (if this expression exists in English). All NoSQL scale

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 06:27 PM, Joel Jacobson wrote: > On Tue, Sep 2, 2014 at 6:11 PM, Álvaro Hernández Tortosa > wrote: >> We are definitely worse. This is the problem, we only look to our own >> belly bottom (if this expression exists in English). All NoSQL scale >> *easily*, *transparently* beyond

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 07:12 PM, Joel Jacobson wrote: On Tue, Sep 2, 2014 at 6:03 PM, Heikki Linnakangas wrote: I think that would actually be a good way to enforce the rule that an UPDATE only updates a single row. Just put a "ASSERT ROW_COUNT=1;" after the update. So instead of one line of code, I w

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 18:20, Joel Jacobson wrote: On Tue, Sep 2, 2014 at 6:09 PM, Kevin Grittner wrote: Joel Jacobson wrote: Sorry for being unclear, I didn't mean to suggest the main concern is updating *all* rows. The main concern is when you have a rather complex UPDATE WHERE clause, aiming to upd

Re: [HACKERS] PL/pgSQL 2

2014-09-02 18:03 GMT+02:00 Heikki Linnakangas : > On 09/02/2014 06:44 PM, Joel Jacobson wrote: > >> On Tue, Sep 2, 2014 at 5:08 PM, Kevin Grittner wrote: >> >>> Marko Tiikkaja wrote: >>> No, but your code can have a bug. >>> >>> So the main use case is to allow buggy functions which ar

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 6:11 PM, Álvaro Hernández Tortosa wrote: > We are definitely worse. This is the problem, we only look to our own > belly bottom (if this expression exists in English). All NoSQL scale > *easily*, *transparently* beyond one node. Postgres doesn't. I'm not saying > they do

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 12:12 PM, Joel Jacobson wrote: On Tue, Sep 2, 2014 at 6:03 PM, Heikki Linnakangas wrote: I think that would actually be a good way to enforce the rule that an UPDATE only updates a single row. Just put a "ASSERT ROW_COUNT=1;" after the update. So instead of one line of code, I w

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 6:09 PM, Kevin Grittner wrote: > Joel Jacobson wrote: > >> Sorry for being unclear, I didn't mean to suggest the main concern is >> updating *all* rows. >> The main concern is when you have a rather complex UPDATE WHERE clause, >> aiming to update exactly one row. Some of t

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 17:03, Hannu Krosing wrote: On 09/02/2014 11:52 AM, Álvaro Hernández Tortosa wrote: On 02/09/14 11:44, Pavel Stehule wrote: For 9.4, we have the media already saying "Postgres has NoSQL capabilities" (which is only partially true). For x.y we could have the me

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 6:03 PM, Heikki Linnakangas wrote: > I think that would actually be a good way to enforce the rule that an UPDATE > only updates a single row. Just put a "ASSERT ROW_COUNT=1;" after the > update. So instead of one line of code, I would need to write two lines of code at alm

  1   2   3   >