Re: [HACKERS] PL/pgSQL 2

Joel Jacobson wrote: > The common use-case I have in mind is when you have a function which > takes some kind of ID as an input param, which maps to a primary key > in some table, which you want to update. > If the where-clause would be incorrect and the update would update all > rows in the tabl

Re: [HACKERS] PL/pgSQL 2

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 are deployed to production without adequate testing to be detected? Bugs like no

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 11:10 PM, Neil Tiffin wrote: > I’d be happy with PL/Javascript, PL/Lua or ?? as long as creating dynamic SQL > queries was simple, i.e. no goofball 6 or 10 level quotes to make it work. > So instead of (from the docs, 40.6.4. Looping Through Query Results) > > EXECUTE 'TRUN

Re: [HACKERS] PL/pgSQL 2

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 are deployed > to production without adequate testing to be detected? Bugs like > not getting the primary key column(s) ri

Re: [HACKERS] PL/pgSQL 2

On 9/2/14 5:08 PM, Kevin Grittner wrote: Marko Tiikkaja wrote: On 9/2/14 4:26 PM, Kevin Grittner wrote: Joel Jacobson wrote: The common use-case I have in mind is when you have a function which takes some kind of ID as an input param, which maps to a primary key in some table, which you want

Re: [HACKERS] PL/pgSQL 2

On Sep 1, 2014, at 10:24 PM, Craig Ringer wrote: > On 09/02/2014 08:09 AM, Neil Tiffin wrote: >> Now I could use other languages as was suggested upstream. Lets see, I use >> R all the time, but R is not a first class language, not in core, and its >> slow. Python 3 would be acceptable to me,

Re: [HACKERS] PL/pgSQL 2

Marko Tiikkaja wrote: > On 9/2/14 4:26 PM, Kevin Grittner wrote: >> Joel Jacobson wrote: >>> The common use-case I have in mind is when you have a function >>> which takes some kind of ID as an input param, which maps to a >>> primary key in some table, which you want to update. >> >> In that cas

Re: [HACKERS] PL/pgSQL 2

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 media saying "Postgres ad

Re: [HACKERS] PL/pgSQL 2

On 9/2/14 4:26 PM, Kevin Grittner wrote: Joel Jacobson wrote: The common use-case I have in mind is when you have a function which takes some kind of ID as an input param, which maps to a primary key in some table, which you want to update. In that case FOUND works just fine. A primary key v

Re: [HACKERS] PL/pgSQL 2

On 9/2/14 4:15 PM, Joel Jacobson wrote: I don't like rebranding the PERFORM command, as that would require all existing code with PERFORM commands to be changed. I'm not saying the suggested syntax is perfect, but PERFORM should be euthanized anyway. Or at least the need for it; perhaps there

Re: [HACKERS] PL/pgSQL 2

Joel Jacobson wrote: > On Tue, Sep 2, 2014 at 3:12 PM, Kevin Grittner wrote: >> 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. >>

Re: [HACKERS] PL/pgSQL 2

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 > > FWIW, I agree with the position that this would be a completely wrong

Re: [HACKERS] PL/pgSQL 2

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 FWIW, I agree with the position that this would be a completely wrong thing to do. UPDATE should work like it does in plain SQL.

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 3:58 PM, Marko Tiikkaja wrote: > When I've played around with the idea of fixing PL/PgSQL in my head, what I > had in mind is that UPDATE and DELETE not affecting exactly one row raises > an exception, unless PERFORM is used. PERFORM would set a special variable > (e.g. ROW

Re: [HACKERS] PL/pgSQL 2

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 add a new syntax to plpgsql, because then we don't have to argue what to

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 04: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 add a new syntax to plpgsql, because then we don't have to argue wha

Re: [HACKERS] PL/pgSQL 2

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 add a new syntax to plpgsql, >> because then we don't have to argue what to call the keyword or where to >> p

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 04:32 PM, Joel Jacobson wrote: On Tue, Sep 2, 2014 at 2:29 PM, Heikki Linnakangas wrote: In the mailing list thread that you linked there, Tom suggested using "STRICT UPDATE ..." to mean that updating 0 or >1 rows is an error (http://www.postgresql.org/message-id/16397.1356106...@

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 2:30 PM, Pavel Stehule wrote: > It is way how to do COBOL from plpgsql. I am against it. Start to develop > new language what will support fast development, but it is wrong way for > plpgsql - and It is out my interest Are you saying COBOL by default update's one row and th

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 2:29 PM, Heikki Linnakangas wrote: > In the mailing list thread that you linked there, Tom suggested using > "STRICT UPDATE ..." to mean that updating 0 or >1 rows is an error > (http://www.postgresql.org/message-id/16397.1356106...@sss.pgh.pa.us). What > happened to that pr

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 3:12 PM, Kevin Grittner wrote: > 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. > > I just embarked on wading th

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 09:08 AM, Pavel Stehule wrote: JavaScript would actually be quite a good alternative. However, using it involves something others have objected to, namely calling SQL via a function call. It's true that plpgsql lets you call SQL commands without explicitly invokin

Re: [HACKERS] PL/pgSQL 2

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. I just embarked on wading through the 99 messages (so far) on this thread, so my apologies i

Re: [HACKERS] PL/pgSQL 2

On 2014-09-02 14:41:03 +0200, Marko Tiikkaja wrote: > On 9/2/14 2:29 PM, Heikki Linnakangas wrote: > >In the mailing list thread that you linked there, Tom suggested using > >"STRICT UPDATE ..." to mean that updating 0 or >1 rows is an error > >(http://www.postgresql.org/message-id/16397.1356106...

Re: [HACKERS] PL/pgSQL 2

2014-09-02 14:38 GMT+02:00 Andrew Dunstan : > > On 09/02/2014 05:44 AM, Álvaro Hernández Tortosa wrote: > >> >> On 02/09/14 11:34, Mark Kirkwood wrote: >> >>> On 02/09/14 21:25, Álvaro Hernández Tortosa wrote: >>> On 02/09/14 05:24, Craig Ringer wrote: > I couldn't disagree more

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 08:41 AM, Ryan Pedela wrote: If PL/Javascript is a serious consideration, how will int64 and numeric be handled? Please don't top-post on the PostgreSQL lists. See Unfortunately, I think the short answer is "not very well". In theory we

Re: [HACKERS] PL/pgSQL 2

On 9/2/14 2:29 PM, Heikki Linnakangas wrote: In the mailing list thread that you linked there, Tom suggested using "STRICT UPDATE ..." to mean that updating 0 or >1 rows is an error (http://www.postgresql.org/message-id/16397.1356106...@sss.pgh.pa.us). What happened to that proposal? http://www

Re: [HACKERS] PL/pgSQL 2

If PL/Javascript is a serious consideration, how will int64 and numeric be handled? Thanks, Ryan Pedela Datalanche CEO, co-founder www.datalanche.com rped...@datalanche.com 513-571-6837 On Tue, Sep 2, 2014 at 6:38 AM, Andrew Dunstan wrote: > > On 09/02/2014 05:44 AM, Álvaro Hernández Tortosa

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 05:44 AM, Álvaro Hernández Tortosa wrote: On 02/09/14 11:34, Mark Kirkwood wrote: On 02/09/14 21:25, Álvaro Hernández Tortosa wrote: On 02/09/14 05:24, Craig Ringer wrote: I couldn't disagree more. If we were to implement anything, it'd be PL/PSM (http://en.wikipedia.org/wiki

Re: [HACKERS] PL/pgSQL 2

2014-09-02 14:16 GMT+02:00 Joel Jacobson : > On Tue, Sep 2, 2014 at 11:04 AM, Pavel Stehule > wrote: > > What we can do better? > > > > 1. we can implement a conditional RAISE > > > > DELETE FROM tab WHERE xx = somevar; > > GET DIAGNOSTICS rc = ROW_COUNT; > > RAISE EXCEPTION 'some' WHEN rc <> 0;

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 03:16 PM, Joel Jacobson wrote: On Tue, Sep 2, 2014 at 11:04 AM, Pavel Stehule wrote: What we can do better? 1. we can implement a conditional RAISE DELETE FROM tab WHERE xx = somevar; GET DIAGNOSTICS rc = ROW_COUNT; RAISE EXCEPTION 'some' WHEN rc <> 0; It is relatively natural

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 11:04 AM, Pavel Stehule wrote: > What we can do better? > > 1. we can implement a conditional RAISE > > DELETE FROM tab WHERE xx = somevar; > GET DIAGNOSTICS rc = ROW_COUNT; > RAISE EXCEPTION 'some' WHEN rc <> 0; > > It is relatively natural and we use similar construct in

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 12:46, Marko Tiikkaja wrote: On 9/2/14 11:40 AM, Álvaro Hernández Tortosa wrote: If we are to have another plpgsql-like language (like plpgsql2) and we could design it so it would attract many many users (let's not forget that Oracle may have around two orders of magnitude mo

Re: [HACKERS] PL/pgSQL 2

On 9/2/14 11:40 AM, Álvaro Hernández Tortosa wrote: If we are to have another plpgsql-like language (like plpgsql2) and we could design it so it would attract many many users (let's not forget that Oracle may have around two orders of magnitude more users than pg), that would benefit us all

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 11:56, Pavel Stehule wrote: 2014-09-02 11:50 GMT+02:00 Álvaro Hernández Tortosa >: On 02/09/14 11:31, Pavel Stehule wrote: 2014-09-02 11:25 GMT+02:00 Álvaro Hernández Tortosa mailto:a...@nosys.es>>: On 02/09/14 05:24, Craig Ringer wro

Re: [HACKERS] PL/pgSQL 2

2014-09-02 11:50 GMT+02:00 Álvaro Hernández Tortosa : > > On 02/09/14 11:31, Pavel Stehule wrote: > > > > > 2014-09-02 11:25 GMT+02:00 Álvaro Hernández Tortosa : > >> >> On 02/09/14 05:24, Craig Ringer wrote: >> >>> I couldn't disagree more. >>> >>> If we were to implement anything, it'd be PL/PSM

Re: [HACKERS] PL/pgSQL 2

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 media saying "Postgres adds Oracle compatibility" (which would be only partially true). But that

Re: [HACKERS] PL/pgSQL 2

2014-09-02 11:44 GMT+02:00 Álvaro Hernández Tortosa : > > On 02/09/14 11:34, Mark Kirkwood wrote: > >> On 02/09/14 21:25, Álvaro Hernández Tortosa wrote: >> >>> >>> On 02/09/14 05:24, Craig Ringer wrote: >>> I couldn't disagree more. If we were to implement anything, it'd be PL/PSM

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 11:31, Pavel Stehule wrote: 2014-09-02 11:25 GMT+02:00 Álvaro Hernández Tortosa >: On 02/09/14 05:24, Craig Ringer wrote: I couldn't disagree more. If we were to implement anything, it'd be PL/PSM (http://en.wikipedia.org/wiki

Re: [HACKERS] PL/pgSQL 2

2014-09-02 11:40 GMT+02:00 Álvaro Hernández Tortosa : > > On 02/09/14 06:40, 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 wor

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 11:34, Mark Kirkwood wrote: On 02/09/14 21:25, Álvaro Hernández Tortosa wrote: On 02/09/14 05:24, Craig Ringer wrote: I couldn't disagree more. If we were to implement anything, it'd be PL/PSM (http://en.wikipedia.org/wiki/SQL/PSM). I'm sure it's as bizarre and quirky as anything

Re: [HACKERS] PL/pgSQL 2

2014-09-02 11:34 GMT+02:00 Marko Tiikkaja : > On 9/2/14 11:04 AM, Pavel Stehule wrote: > >> It is relatively natural and we use similar construct in CONTINUE >> statement. >> >> 2. What can be next? We can implement some idiom (shortcut) for GET >> DIAGNOSTICS >> >> DELETE FROM tab WHERE xx = some

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 06:40, 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 it to cashed-up Oracle users loo

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 21:25, Álvaro Hernández Tortosa wrote: On 02/09/14 05:24, Craig Ringer wrote: I couldn't disagree more. If we were to implement anything, it'd be PL/PSM (http://en.wikipedia.org/wiki/SQL/PSM). I'm sure it's as bizarre and quirky as anything else the SQL committee has brought forth,

Re: [HACKERS] PL/pgSQL 2

On 9/2/14 11:04 AM, Pavel Stehule wrote: It is relatively natural and we use similar construct in CONTINUE statement. 2. What can be next? We can implement some idiom (shortcut) for GET DIAGNOSTICS DELETE FROM tab WHERE xx = somevar; RAISE EXCEPTION 'some' WHEN AFFECTED_ROW_COUNT <> 1; Yes, a

Re: [HACKERS] PL/pgSQL 2

2014-09-02 11:25 GMT+02:00 Álvaro Hernández Tortosa : > > On 02/09/14 05:24, Craig Ringer wrote: > >> I couldn't disagree more. >> >> If we were to implement anything, it'd be PL/PSM >> (http://en.wikipedia.org/wiki/SQL/PSM). I'm sure it's as bizarre and >> quirky as anything else the SQL committe

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 05:24, Craig Ringer wrote: I couldn't disagree more. If we were to implement anything, it'd be PL/PSM (http://en.wikipedia.org/wiki/SQL/PSM). I'm sure it's as bizarre and quirky as anything else the SQL committee has brought forth, but it's at least a standard(ish) language. So

Re: [HACKERS] PL/pgSQL 2

2014-09-01 11:04 GMT+02:00 Joel Jacobson : > 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 least in theor

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 8:26 AM, Heikki Linnakangas wrote: > On 09/02/2014 09:06 AM, Joel Jacobson wrote: >> For me, the most important is to not break *most* of existing plpgsql >> code, but it's OK to break *some*. >> And when breaking it, it should be trivial to rewrite it to become >> compatibl

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 09:06 AM, Joel Jacobson wrote: Given the needed diff between plpgsql and plpgsql2 for the changes I'm mostly interested in would probably be quite small, I'm in favour of Tom's suggestion of: c) plpgsql and plpgsql2 are the same code base, with a small number of places that act dif

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 5:46 AM, Craig Ringer wrote: > My point is that weeks can be spent just arguing about whether you > should have a variable-delimiter ($variable) or not, how syntax should > look, etc. Imagine how long it'd take to get a new language syntax > agreed upon? I would guess about

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 12:40 PM, Tom Lane 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

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 it to > cashed-up Oracle users looking to save a few hundred gran

Re: [HACKERS] PL/pgSQL 2

On 14/09/02 12:24, Craig Ringer wrote: > On 09/02/2014 08:09 AM, Neil Tiffin wrote: (...) >> That should be enough alone to suggest postgreSQL start working on a modern, >> in core, fast, fully supported language. > > I couldn't disagree more. > > If we were to implement anything, it'd be PL/PS

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 15:46, Craig Ringer wrote: was "is exactly why we need a new language" and that "All the clumsy stuff we cannot fix in plpgsql, can easily be fixed in plpgsql2, with the most beautiful syntax we can come up with." But you haven't said HOW you propose to fix this one case. Unfortuna

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 11:42 AM, David Johnston wrote: > > ​Yet pl/pgsql does not have to use SPI-interface type calls to interact > with PostgreSQL at the SQL level... That's right. > ​I don't have an answer to your questions but the one I'm asking is > whether a particular language could hide all of th

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 11:19 PM, Joel Jacobson wrote: > On Mon, Sep 1, 2014 at 5:16 PM, Craig Ringer wrote: >> On 09/01/2014 10:41 PM, Joel Jacobson wrote: >>> This is exactly why we need a new language. >>> All the clumsy stuff we cannot fix in plpgsql, can easily be fixed in >>> plpgsql2, with the most b

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 11:12 PM, Craig Ringer wrote: > On 09/02/2014 09:40 AM, David G Johnston wrote: > > Random thought as I wrote that: how about considering how pl/pgsql > > functionality can be generalize so that it is a database API that > > another language can call? In that way the serve

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 05:46 AM, David G Johnston wrote: > The goal of adding PL/SQL would be to increase the user base of the project > and hopefully attract new blood to the development team in order to maximize > long-term survivability and increase the pace of innovation. We would be > unable to introd

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 08:09 AM, Neil Tiffin wrote: > Now I could use other languages as was suggested upstream. Lets see, I use R > all the time, but R is not a first class language, not in core, and its slow. > Python 3 would be acceptable to me, but its untrusted. tcl I don’t know and > don’t want to

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 09:40 AM, David G Johnston wrote: > Random thought as I wrote that: how about considering how pl/pgsql > functionality can be generalize so that it is a database API that > another language can call? In that way the server would drive the core > functionality and the language would s

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 9:07 PM, Andrew Dunstan [via PostgreSQL] < ml-node+s1045698n5817265...@n5.nabble.com> wrote: > > On 09/01/2014 08:09 PM, Neil Tiffin wrote: > > > > 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 09/01/2014 08:09 PM, Neil Tiffin wrote: On Sep 1, 2014, at 10:45 AM, Tom Lane wrote: What is actually being proposed, AFAICS, is a one-shot fix for a bunch of unfortunate choices. That might be worth doing, but let's not fool ourselves about whether it’s one-shot or not. Well, one shot e

Re: [HACKERS] PL/pgSQL 2

On Sep 1, 2014, at 10:45 AM, Tom Lane wrote: > What is actually being proposed, AFAICS, is a one-shot fix for a bunch > of unfortunate choices. That might be worth doing, but let's not fool > ourselves about whether it’s one-shot or not. Well, one shot every 18 years is not so bad. I am only

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 23:46, David G Johnston wrote: Álvaro Hernández Tortosa wrote On 01/09/14 21:52, Joel Jacobson wrote: On Mon, Sep 1, 2014 at 8:34 PM, Álvaro Hernández Tortosa < aht@ > wrote: What I can add is that, if Postgres is to devote resources to a new language, I would plan it with

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 23:31, Marko Tiikkaja wrote: On 2014-09-01 11:11 PM, Álvaro Hernández Tortosa wrote: No, really: if there is a new version of a "language", which modifies the current syntax of plpgsql; if plpgsql is already very similar to PL/SQL: why not rather than coming up with a new synt

Re: [HACKERS] PL/pgSQL 2

Álvaro Hernández Tortosa wrote > On 01/09/14 21:52, Joel Jacobson wrote: >> On Mon, Sep 1, 2014 at 8:34 PM, Álvaro Hernández Tortosa < > aht@ > > wrote: >>> What I can add is that, if Postgres is to devote resources to a new >>> language, I would plan it with a broader scope. What would attr

Re: [HACKERS] PL/pgSQL 2

On 2014-09-01 11:11 PM, Álvaro Hernández Tortosa wrote: No, really: if there is a new version of a "language", which modifies the current syntax of plpgsql; if plpgsql is already very similar to PL/SQL: why not rather than coming up with a new syntax use an already existing one? One that ma

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 21:52, Joel Jacobson wrote: On Mon, Sep 1, 2014 at 8:34 PM, Álvaro Hernández Tortosa wrote: What I can add is that, if Postgres is to devote resources to a new language, I would plan it with a broader scope. What would attract most users? Would it bring non postgres users to P

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 21:08, Pavel Stehule wrote: 2014-09-01 20:58 GMT+02:00 Álvaro Hernández Tortosa >: On 01/09/14 20:42, Tom Lane wrote: =?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= mailto:a...@nosys.es>> writes: What I can add is that, if

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 8:34 PM, Álvaro Hernández Tortosa wrote: > What I can add is that, if Postgres is to devote resources to a new > language, I would plan it with a broader scope. What would attract most > users? Would it bring non postgres users to Postgres? What could be one of > the kil

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 8:38 PM, Tom Lane wrote: > c) plpgsql and plpgsql2 are the same code base, with a small number > of places that act differently depending on the language version. +1 to the idea -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] PL/pgSQL 2

2014-09-01 20:58 GMT+02:00 Álvaro Hernández Tortosa : > > On 01/09/14 20:42, Tom Lane wrote: > >> =?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= writes: >> >>> What I can add is that, if Postgres is to devote resources to a new >>> language, I would plan it with a broader scope. What woul

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 20:42, Tom Lane wrote: =?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= writes: What I can add is that, if Postgres is to devote resources to a new language, I would plan it with a broader scope. What would attract most users? Would it bring non postgres users to Postgres? Wh

Re: [HACKERS] PL/pgSQL 2

=?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= writes: > What I can add is that, if Postgres is to devote resources to a new > language, I would plan it with a broader scope. What would attract most > users? Would it bring non postgres users to Postgres? What could be one > of the killer

Re: [HACKERS] PL/pgSQL 2

Joel Jacobson writes: > I see two possible approaches of a plpgsql2 project, both aiming to > require minimal/no changes of most existing best-practice plpgsql > code: > a) fork plpgsql code base and implement changes with as few lines of > code as possible, making it easier to understand the chan

Re: [HACKERS] PL/pgSQL 2

2014-09-01 20:23 GMT+02:00 Joel Jacobson : > On Mon, Sep 1, 2014 at 5:45 PM, Tom Lane wrote: > > What is actually being proposed, AFAICS, is a one-shot fix for a bunch > > of unfortunate choices. That might be worth doing, but let's not fool > > ourselves about whether it's one-shot or not. > >

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 14:27, Joel Jacobson wrote: On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule wrote: I agree with Andres - it is not a good for plpgsql and for plpgsql users. The benefit must be significant for 90% of users. ... Official implementation of plpgsql2 can be very wrong and dangerous sig

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 5:45 PM, Tom Lane wrote: > What is actually being proposed, AFAICS, is a one-shot fix for a bunch > of unfortunate choices. That might be worth doing, but let's not fool > ourselves about whether it's one-shot or not. I'm glad to hear you think it *might* be worth doing. A

Re: [HACKERS] PL/pgSQL 2

Andres Freund writes: > On 2014-09-01 15:19:41 +0200, Joel Jacobson wrote: >> On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule >> wrote: >>> It bad signal to have two languages plpgsql and plpgsql2. Who will believe >>> to us so we will continue development of plpgsql? >> Depends on how you define

Re: [HACKERS] PL/pgSQL 2

Joel Jacobson-2 wrote > On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer < > craig@ > > 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 clums

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 5:16 PM, Craig Ringer wrote: > On 09/01/2014 10:41 PM, Joel Jacobson wrote: >> This is exactly why we need a new language. >> All the clumsy stuff we cannot fix in plpgsql, can easily be fixed in >> plpgsql2, with the most beautiful syntax we can come up with. >> >> I guess

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 10:41 PM, Joel Jacobson wrote: > This is exactly why we need a new language. > All the clumsy stuff we cannot fix in plpgsql, can easily be fixed in > plpgsql2, with the most beautiful syntax we can come up with. > > I guess it's a question if we want to support things like this. If

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 4:41 PM, Andres Freund wrote: >> I'm just saying it's much less probable you can add new features to >> plpgsql than to plpgsql2, as you have to take into account the risk of >> breaking compatibility. > > That's just a difference of one release. The release after the set of

Re: [HACKERS] PL/pgSQL 2

2014-09-01 16:41 GMT+02:00 Joel Jacobson : > 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. > A

Re: [HACKERS] PL/pgSQL 2

2014-09-01 16:39 GMT+02:00 Hannu Krosing : > On 09/01/2014 03:45 PM, Craig Ringer wrote: > > On 09/01/2014 05:04 PM, Joel Jacobson wrote: > >> Just like with plpgsql, once released, plpgsql2 cannot break > >> compatibility with future versions, so we only have one chance to > >> carefully think th

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 05:41 PM, 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. We could certainly i

Re: [HACKERS] PL/pgSQL 2

On 2014-09-01 16:29:18 +0200, Joel Jacobson wrote: > On Mon, Sep 1, 2014 at 3:25 PM, Andres Freund wrote: > > On 2014-09-01 15:19:41 +0200, Joel Jacobson wrote: > >> On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule > >> wrote: > >> > It bad signal to have two languages plpgsql and plpgsql2. Who wil

Re: [HACKERS] PL/pgSQL 2

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 cannot fix in plpgsql, can easily be fix

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 03:45 PM, Craig Ringer wrote: > On 09/01/2014 05:04 PM, Joel Jacobson wrote: >> Just like with plpgsql, once released, plpgsql2 cannot break >> compatibility with future versions, so we only have one chance to >> carefully think though what we would like to change in the language. > Y

Re: [HACKERS] PL/pgSQL 2

2014-09-01 16:26 GMT+02:00 Craig Ringer : > On 09/01/2014 10:24 PM, Andres Freund wrote: > > I know of format(), but it doesn't allow you to pass parameters as > > actual query variables unfortunately. > > I'm wondering if there's a way to marry USING and format()... > > Well, the idiom: > > EXE

Re: [HACKERS] PL/pgSQL 2

+1 I use underscore for *all* variables and input parameters in all functions. Making that a requirement in plpgsql2 wouldn't break any of my code. On Mon, Sep 1, 2014 at 3:52 PM, Craig Ringer wrote: > On 09/01/2014 05:04 PM, Joel Jacobson wrote: >> From the top of my head, these are Things I pe

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 3:25 PM, Andres Freund wrote: > On 2014-09-01 15:19:41 +0200, Joel Jacobson wrote: >> On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule >> wrote: >> > It bad signal to have two languages plpgsql and plpgsql2. Who will believe >> > to us so we will continue development of plpgs

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 10:24 PM, Andres Freund wrote: > I know of format(), but it doesn't allow you to pass parameters as > actual query variables unfortunately. > I'm wondering if there's a way to marry USING and format()... Well, the idiom: EXECUTE format("SELECT %I FROM %I WHERE $1", col, tbl) USING

Re: [HACKERS] PL/pgSQL 2

On 2014-09-01 22:20:37 +0800, Craig Ringer wrote: > On 09/01/2014 10:17 PM, Andres Freund wrote: > > Imo this is still something that's more dynamic SQL (i.e. EXECUTE's > > remit) than something that shouldn't be doable implicitly. So perhaps > > the solution is to extend EXECUTE to allow specifyin

Re: [HACKERS] PL/pgSQL 2

2014-09-01 16:18 GMT+02:00 Craig Ringer : > On 09/01/2014 10:11 PM, Pavel Stehule wrote: > > > > It can be solution, but I dislike it .. It increase a language > > complexity .. vars with or without prefix .. and more, hidden dynamic > SQL > > > > Nothing what I like - I have a mental barrier to

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 10:17 PM, Andres Freund wrote: > Imo this is still something that's more dynamic SQL (i.e. EXECUTE's > remit) than something that shouldn't be doable implicitly. So perhaps > the solution is to extend EXECUTE to allow specifying tablenames as > variables more conveniently? With forma

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 10:11 PM, Pavel Stehule wrote: > > It can be solution, but I dislike it .. It increase a language > complexity .. vars with or without prefix .. and more, hidden dynamic SQL > > Nothing what I like - I have a mental barrier to this concept. Yeah - the question is whether it's bet

Re: [HACKERS] PL/pgSQL 2

On 2014-09-01 22:01:33 +0800, Craig Ringer wrote: > On 09/01/2014 09:58 PM, Pavel Stehule wrote: > > > > It is in ToDo - allow parametrization for COMMANDs. > > > > But this is one point, when I am not sure if we would it. Now - > > situation is very simply. Variables should not be used as table

Re: [HACKERS] PL/pgSQL 2

2014-09-01 16:01 GMT+02:00 Craig Ringer : > On 09/01/2014 09:58 PM, Pavel Stehule wrote: > > > > It is in ToDo - allow parametrization for COMMANDs. > > > > But this is one point, when I am not sure if we would it. Now - > > situation is very simply. Variables should not be used as table or > > co

<    1   2   3   >