Re: [HACKERS] merging some features from plpgsql2 project

On 1/11/17 12:07 PM, Pavel Stehule wrote: PL/SQL = ADA + Oracle SQL; -- but sometimes the result is not perfect - Ada was not designed be integrated with SQL ... There is a language that is much better integrated with SQL - SQL/PSM I think it is worth considering ways to increase

Re: [HACKERS] merging some features from plpgsql2 project

On Wed, Jan 11, 2017 at 2:57 PM, Robert Haas wrote: > - The E'' syntax and the standard_conforming_strings GUC were added in > PostgreSQL 8.0. The only legal value of standard_conforming_strings > was "false". > > - In PostgreSQL 8.1, it became possible to set >

Re: [HACKERS] merging some features from plpgsql2 project

On Mon, Jan 9, 2017 at 6:53 PM, Jim Nasby wrote: > I do think that whichever route we go, we're going to be stuck supporting > the old version for a LONG time. A big part of why > standard_conforming_strings was so ugly is users didn't have enough time to > adjust. If

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-11 20:53 GMT+01:00 Merlin Moncure : > On Wed, Jan 11, 2017 at 11:11 AM, Peter Eisentraut > wrote: > > The current syntax was chosen because it is SQL-compatible. Adding > > redundant syntax to save a few characters without any new

Re: [HACKERS] merging some features from plpgsql2 project

On Wed, Jan 11, 2017 at 11:11 AM, Peter Eisentraut wrote: > The current syntax was chosen because it is SQL-compatible. Adding > redundant syntax to save a few characters without any new functionality > (performance, resource usage, safety, etc.) is a weak

Re: [HACKERS] merging some features from plpgsql2 project

On 1/10/17 8:44 AM, Marko Tiikkaja wrote: > On Tue, Jan 10, 2017 at 2:26 PM, Peter Eisentraut > > wrote: > > It's not like PL/pgSQL is the king of brevity. > > > This is essentially saying "PL/PgSQL isn't

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-11 15:37 GMT+01:00 Merlin Moncure : > On Tue, Jan 10, 2017 at 7:44 AM, Marko Tiikkaja wrote: > > On Tue, Jan 10, 2017 at 2:26 PM, Peter Eisentraut > > wrote: > >> > >> It's not like PL/pgSQL is the king of brevity. > >

Re: [HACKERS] merging some features from plpgsql2 project

On Tue, Jan 10, 2017 at 7:44 AM, Marko Tiikkaja wrote: > On Tue, Jan 10, 2017 at 2:26 PM, Peter Eisentraut > wrote: >> >> It's not like PL/pgSQL is the king of brevity. > > > This is essentially saying "PL/PgSQL isn't perfect, so we shouldn't try

Re: [HACKERS] merging some features from plpgsql2 project

On Tue, Jan 10, 2017 at 2:26 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > It's not like PL/pgSQL is the king of brevity. This is essentially saying "PL/PgSQL isn't perfect, so we shouldn't try and make it better". I hear this argument a lot, and as long as people keep

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-10 14:26 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 1/10/17 12:06 AM, Pavel Stehule wrote: > > A check how much rows was impacted by query is relative often task. So > > we can do this task more user friendly. > > > > Second motivation - ROW_COUNT is working for

Re: [HACKERS] merging some features from plpgsql2 project

On 1/10/17 12:06 AM, Pavel Stehule wrote: > A check how much rows was impacted by query is relative often task. So > we can do this task more user friendly. > > Second motivation - ROW_COUNT is working for static and for dynamic SQL > - it can be partial replace of FOUND variable. What is

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-10 5:59 GMT+01:00 Peter Eisentraut : > On 1/7/17 6:39 AM, Pavel Stehule wrote: > > ROW_COUNT .. shortcut for GET DIAGNOSTICS row_count = ROW_COUNT. > > I don't see the point. > A check how much rows was impacted by query is relative often task. So we

Re: [HACKERS] merging some features from plpgsql2 project

On 1/7/17 6:39 AM, Pavel Stehule wrote: > ROW_COUNT .. shortcut for GET DIAGNOSTICS row_count = ROW_COUNT. I don't see the point. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-10 2:02 GMT+01:00 Jim Nasby : > On 1/9/17 6:07 PM, Marko Tiikkaja wrote: > >> One use case is NEW and OLD in triggers. Checking to see if one or >> the other is set is easier than checking TG_OP. It's also going to >> be faster (probably MUCH faster;

Re: [HACKERS] merging some features from plpgsql2 project

On 1/9/17 6:07 PM, Marko Tiikkaja wrote: One use case is NEW and OLD in triggers. Checking to see if one or the other is set is easier than checking TG_OP. It's also going to be faster (probably MUCH faster; IIRC the comparison currently happens via SPI). This sounds useless.

Re: [HACKERS] merging some features from plpgsql2 project

On Tue, Jan 10, 2017 at 1:03 AM, Jim Nasby wrote: > On 1/9/17 5:53 PM, Marko Tiikkaja wrote: > >> My idea was that the currently unsupported combination of NOT >> NULL and >> no DEFAULT would mean "has to be assigned to a non-NULL value >>

Re: [HACKERS] merging some features from plpgsql2 project

On 1/9/17 5:53 PM, Marko Tiikkaja wrote: My idea was that the currently unsupported combination of NOT NULL and no DEFAULT would mean "has to be assigned to a non-NULL value before it can be read from, or an exception is thrown". Solves the most

Re: [HACKERS] merging some features from plpgsql2 project

On 1/9/17 3:01 AM, Pavel Stehule wrote: You are forgot on function paramaters - somebody can use a function argument like FOUND, .. So auto variables should to be declared in most top namespace. Right, that's why I said it was an alternative. I agree it would be better to just have 2

Re: [HACKERS] merging some features from plpgsql2 project

On 1/9/17 5:12 PM, Merlin Moncure wrote: Agreed: If you want to break compatibility, pushing a new language is the better way than GUC. If you got consensus on this, having both languages side by side supported for a while (maybe 4-5 releases) is they way to go, and finally the only language

Re: [HACKERS] merging some features from plpgsql2 project

On Tue, Jan 10, 2017 at 12:47 AM, Jim Nasby wrote: > On 1/9/17 5:30 PM, Marko Tiikkaja wrote: > My idea was that the currently unsupported combination of NOT NULL and >> no DEFAULT would mean "has to be assigned to a non-NULL value before it >> can be read from, or an

Re: [HACKERS] merging some features from plpgsql2 project

On 1/9/17 5:30 PM, Marko Tiikkaja wrote: This is exactly what we did not want to do with this project. The idea is to create a language which is really close to PL/PgSQL, but removes some of the brain diarrhoea currently present. As a general comment, ISTM it'd be much better to do as much

Re: [HACKERS] merging some features from plpgsql2 project

On 01/09/2017 06:12 PM, Merlin Moncure wrote: With respect to your company developers specifically? I'm genuinely curious if you've taken a good look at pl/v8 and why you've determined it's not suitable to move forward with. It's got a different set of headaches, but is really fast, and

Re: [HACKERS] merging some features from plpgsql2 project

On Mon, Jan 9, 2017 at 12:37 AM, Jim Nasby wrote: > If we're going to create a brand new language then I think it would be > extremely foolish to keep *any* of the current pain points around. Off the > top of my head: > > - variables must have an identifier (what $ in

Re: [HACKERS] merging some features from plpgsql2 project

On Sun, Jan 8, 2017 at 2:52 AM, Joel Jacobson wrote: > On Sat, Jan 7, 2017 at 8:56 PM, Pavel Stehule wrote: >> >> Jim, Marko, Joel - is there a place, features where we can find a partial >> agreement? If it is, then we can move our view there. > > I

Re: [HACKERS] merging some features from plpgsql2 project

Hi > > Real support for using variables as identifiers / nothing restricted to > only accepting a Const. > This point is problematic not only from performance perspective. if you don't use some special syntax and you allow variables as identifier, then you will got a ambiguous situation

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-09 0:39 GMT+01:00 Jim Nasby : > On 1/7/17 11:44 PM, Pavel Stehule wrote: > >> This is not overloading of SQL command - it is like annotations. It is >> smart idea, so I was not surprised if ANSI/SQL reuses it. >> > > SHas ANSI declared that they will NEVER

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-09 1:10 GMT+01:00 Jim Nasby : > On 1/8/17 12:03 AM, Pavel Stehule wrote: > >> BTW, I do wish you could change the label of the scope that >> arguments went into, so that you could use that label to refer >> to function parameters. If we

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-09 0:37 GMT+01:00 Jim Nasby : > On 1/8/17 2:52 AM, Joel Jacobson wrote: > >> And please kill all these GUCs ideas. The best thing with PostgreSQL >> is the natural expected behaviour of the default configuration. >> Contrary to MySQL where you have to enable lots

Re: [HACKERS] merging some features from plpgsql2 project

On 1/8/17 12:03 AM, Pavel Stehule wrote: BTW, I do wish you could change the label of the scope that arguments went into, so that you could use that label to refer to function parameters. If we allowed that it'd perhaps be the best of both worlds: you'd be

Re: [HACKERS] merging some features from plpgsql2 project

On 1/7/17 11:44 PM, Pavel Stehule wrote: This is not overloading of SQL command - it is like annotations. It is smart idea, so I was not surprised if ANSI/SQL reuses it. SHas ANSI declared that they will NEVER support := in a SELECT that's not running in a stored function? Because if they

Re: [HACKERS] merging some features from plpgsql2 project

On 1/8/17 2:52 AM, Joel Jacobson wrote: And please kill all these GUCs ideas. The best thing with PostgreSQL is the natural expected behaviour of the default configuration. Contrary to MySQL where you have to enable lots and lots of configuration options just to get a behaviour you expect as a

Re: [HACKERS] merging some features from plpgsql2 project

On Sat, Jan 7, 2017 at 8:56 PM, Pavel Stehule wrote: > > Jim, Marko, Joel - is there a place, features where we can find a partial > agreement? If it is, then we can move our view there. I have decided I definitively want a new language, and I'm willing to pay for it.

Re: [HACKERS] merging some features from plpgsql2 project

> >> Related to that, I suspect we could add better support to existing >> commands for at least some of these things. For example, SELECT ... INTO >> NOMULTI (instead of STRICT) to indicate that multiple rows are an error but >> missing data is > > > Another flag into NOMULTI can be solution too.

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-08 3:27 GMT+01:00 Jim Nasby : > On 1/5/17 11:36 AM, Merlin Moncure wrote: > >> The C language really should be considered the gold standard here. >> Changes did have to be made, like getting rid of the notoriously >> broken and insecure gets(), but they were made

Re: [HACKERS] merging some features from plpgsql2 project

> > >> >> BTW, I do wish you could change the label of the scope that arguments >> went into, so that you could use that label to refer to function >> parameters. If we allowed that it'd perhaps be the best of both worlds: >> you'd be guaranteed access to all auto variables and parameters, and

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-08 3:31 GMT+01:00 Jim Nasby : > On 1/7/17 5:39 AM, Pavel Stehule wrote: > >> >> I checked current implementation of FOUND variable. If we introduce new >> auto variable ROW_COUNT - exactly like FOUND, then it doesn't introduce >> any compatibility break. >> > >

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-08 3:39 GMT+01:00 Jim Nasby : > On 1/7/17 2:06 AM, Pavel Stehule wrote: > >> >> SELECT t1 := c1, t2 := c2, ... >> >> - it can be PostgreSQL specific syntax - full control over design >> - maximally robust against typo >> - long syntax, but for short syntax

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-08 4:11 GMT+01:00 Jim Nasby : > On 1/7/17 8:53 PM, Tom Lane wrote: > >> If FOUND were declared at an outer scoping level such that any >> user-created declaration overrode the name, then we could do likewise >> for other auto variables and not fear compatibility

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-08 3:53 GMT+01:00 Tom Lane : > Jim Nasby writes: > > On 1/7/17 5:39 AM, Pavel Stehule wrote: > >> I checked current implementation of FOUND variable. If we introduce new > >> auto variable ROW_COUNT - exactly like FOUND, then it doesn't

Re: [HACKERS] merging some features from plpgsql2 project

On 1/7/17 8:53 PM, Tom Lane wrote: If FOUND were declared at an outer scoping level such that any user-created declaration overrode the name, then we could do likewise for other auto variables and not fear compatibility breaks. Currently, though, we don't seem to be quite there: it looks like

Re: [HACKERS] merging some features from plpgsql2 project

Jim Nasby writes: > On 1/7/17 5:39 AM, Pavel Stehule wrote: >> I checked current implementation of FOUND variable. If we introduce new >> auto variable ROW_COUNT - exactly like FOUND, then it doesn't introduce >> any compatibility break. > Except it would break every

Re: [HACKERS] merging some features from plpgsql2 project

On 1/7/17 2:06 AM, Pavel Stehule wrote: SELECT t1 := c1, t2 := c2, ... - it can be PostgreSQL specific syntax - full control over design - maximally robust against typo - long syntax, but for short syntax can be used SELECT c1,c2,c3, .. INTO STRICT recvar I don't think overloading a SQL

Re: [HACKERS] merging some features from plpgsql2 project

On 1/7/17 5:39 AM, Pavel Stehule wrote: I checked current implementation of FOUND variable. If we introduce new auto variable ROW_COUNT - exactly like FOUND, then it doesn't introduce any compatibility break. Except it would break every piece of code that had a row_count variable, though I

Re: [HACKERS] merging some features from plpgsql2 project

On 1/5/17 11:36 AM, Merlin Moncure wrote: The C language really should be considered the gold standard here. Changes did have to be made, like getting rid of the notoriously broken and insecure gets(), but they were made very, very slowly and unobtrusively. For those not familiar... how did

Re: [HACKERS] merging some features from plpgsql2 project

> > > * EXECUTE and FOUND - this is incompatible change, extra check can be used > (test on unset variable). I see solution in leaving FOUND variable and > introduction of some new without this issue - ROW_COUNT maybe (this is > another possible incompatible change, but with higher benefit - maybe

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-03 17:57 GMT+01:00 Jim Nasby : > On 1/2/17 1:51 PM, Pavel Stehule wrote: > >> 1) Neither is enabled by default, so 90% of users have no idea they >> exist. Obviously that's an easy enough fix, but... >> >> We can strongly talk about it - there can be a

Re: [HACKERS] merging some features from plpgsql2 project

On Thu, Jan 5, 2017 at 7:03 AM, Robert Haas wrote: > > I think it would be a good idea to lock all the people who really care > about PL/pgsql in a room until they agree on what changes should be > made for the next version of the language. If they don't agree > quickly

Re: [HACKERS] merging some features from plpgsql2 project

Hi > > > > > some examples based on Ada doc > > > > FUNCTION xxx RETURN int AS > > PRAGMA yyy -- pragma has function scope > > BEGIN > > > > FUNCTION xxx RETURN int AS > > BEGIN > > DECLARE > > PRAGMA yyy -- pragma has block scope > > ok, sub-block makes sense over statement level IMO. >

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-05 18:36 GMT+01:00 Merlin Moncure : > On Thu, Jan 5, 2017 at 11:03 AM, Robert Haas > wrote: > > Now, that's not to say we should never break backward compatibility. > > Sometimes we should. I think the problem with PL/pgsql is that many > > of

Re: [HACKERS] merging some features from plpgsql2 project

On Thu, Jan 5, 2017 at 11:03 AM, Robert Haas wrote: > Now, that's not to say we should never break backward compatibility. > Sometimes we should. I think the problem with PL/pgsql is that many > of the compatibility breaks that people want are likely to lead to > subtle

Re: [HACKERS] merging some features from plpgsql2 project

On Wed, Dec 28, 2016 at 2:25 PM, Jim Nasby wrote: > That's my whole point of why this needs to be settable at a global level: so > that people with a lot of legacy code can set the OLD behavior at a global > level, and deal with the old code over time. This has the same

Re: [HACKERS] merging some features from plpgsql2 project

On Wed, Jan 4, 2017 at 1:49 PM, Pavel Stehule wrote: > >> >> so some possible design can be: >> >> DECLARE >> PRAGMA UNCACHED_PLANS; >> BEGIN >> SELECT ... INTO ; >> SELECT ... INTO ; >> END; >> >> This respects Ada and PL/SQL style - probably easy implementation >>

Re: [HACKERS] merging some features from plpgsql2 project

> > so some possible design can be: > > DECLARE > PRAGMA UNCACHED_PLANS; > BEGIN > SELECT ... INTO ; > SELECT ... INTO ; > END; > > This respects Ada and PL/SQL style - probably easy implementation > > Regards > > Pavel > some examples based on Ada doc FUNCTION xxx RETURN int AS PRAGMA

Re: [HACKERS] merging some features from plpgsql2 project

> > >> >> >> >> >> >> *) Some user visible mechanic other than forcing SQL through EXECUTE >> >> >> to be able to control plan caching would be useful. >> >> > >> >> > fully agree. >> >> > >> >> > Have you some ideas? >> >> > >> >> > What about plpgsql option (function scope) -- WITHOUT-PLAN-CACHE

Re: [HACKERS] merging some features from plpgsql2 project

>> > SELECT UNCACHED t.a, t.b FROM INTO a,b; >> >> Yeah -- this is pretty ugly admittedly. Maybe control directive is >> ok, as long as you can set it mid function? >> > > ADA uses for this purpose PRAGMA keyword - it is used for everything in > ADA - cycle iteration optimization, ...the scope

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-04 16:49 GMT+01:00 Merlin Moncure : > On Tue, Jan 3, 2017 at 2:15 PM, Pavel Stehule > wrote: > > > > > > 2017-01-03 20:54 GMT+01:00 Merlin Moncure : > >> > >> On Tue, Jan 3, 2017 at 9:58 AM, Pavel Stehule

Re: [HACKERS] merging some features from plpgsql2 project

On Tue, Jan 3, 2017 at 2:15 PM, Pavel Stehule wrote: > > > 2017-01-03 20:54 GMT+01:00 Merlin Moncure : >> >> On Tue, Jan 3, 2017 at 9:58 AM, Pavel Stehule >> wrote: >> > 2017-01-03 16:23 GMT+01:00 Merlin Moncure

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-03 20:54 GMT+01:00 Merlin Moncure : > On Tue, Jan 3, 2017 at 9:58 AM, Pavel Stehule > wrote: > > 2017-01-03 16:23 GMT+01:00 Merlin Moncure : > >> So -1 to strict mode, unless we can make a case why this can't be done > >>

Re: [HACKERS] merging some features from plpgsql2 project

On Tue, Jan 3, 2017 at 9:58 AM, Pavel Stehule wrote: > 2017-01-03 16:23 GMT+01:00 Merlin Moncure : >> So -1 to strict mode, unless we can make a case why this can't be done >> as part of checking/validation. > > Can be plpgsq.extra_errors and

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-03 18:41 GMT+01:00 Jim Nasby : > On 1/3/17 11:19 AM, Pavel Stehule wrote: > >> 2) There's no way to incrementally change those values for a >> single >> function. If you've set extra_errors = 'all' globally, a >> single >>

Re: [HACKERS] merging some features from plpgsql2 project

On 1/3/17 11:19 AM, Pavel Stehule wrote: 2) There's no way to incrementally change those values for a single function. If you've set extra_errors = 'all' globally, a single function can't say "turn off the too many rows setting for this

Re: [HACKERS] merging some features from plpgsql2 project

On 1/3/17 9:58 AM, Pavel Stehule wrote: > ** The real problem is that we have no mechanism for allowing a PL's > language/syntax/API to move forward without massive backwards compatibility > problems. ** Just got back from break :-). Have some thoughts on this. Backwards

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-03 17:57 GMT+01:00 Jim Nasby : > On 1/2/17 1:51 PM, Pavel Stehule wrote: > >> 1) Neither is enabled by default, so 90% of users have no idea they >> exist. Obviously that's an easy enough fix, but... >> >> We can strongly talk about it - there can be a

Re: [HACKERS] merging some features from plpgsql2 project

On 1/2/17 1:51 PM, Pavel Stehule wrote: 1) Neither is enabled by default, so 90% of users have no idea they exist. Obviously that's an easy enough fix, but... We can strongly talk about it - there can be a chapter in plpgsql doc. Now, the patterns and antipatterns are not officially

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-03 16:23 GMT+01:00 Merlin Moncure : > On Tue, Dec 27, 2016 at 10:09 PM, Jim Nasby > wrote: > > On 12/27/16 4:56 PM, Merlin Moncure wrote: > >> > >> On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule > > >> wrote: > >>>

Re: [HACKERS] merging some features from plpgsql2 project

On Tue, Dec 27, 2016 at 10:09 PM, Jim Nasby wrote: > On 12/27/16 4:56 PM, Merlin Moncure wrote: >> >> On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule >> wrote: >>> >>> First I describe my initial position. I am strongly against introduction >>>

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-02 20:16 GMT+01:00 Jim Nasby : > On 1/2/17 12:06 PM, Pavel Stehule wrote: > >> SELECT (polymorphiccomposite).* INTO c1, c2; -- take first two columns >> >> SELECT xx FROM tab ORDER BY yy INTO target -- more rows not a issue >> >> I understand plpgsql_extra_errors

Re: [HACKERS] merging some features from plpgsql2 project

On 1/2/17 12:06 PM, Pavel Stehule wrote: SELECT (polymorphiccomposite).* INTO c1, c2; -- take first two columns SELECT xx FROM tab ORDER BY yy INTO target -- more rows not a issue I understand plpgsql_extra_errors as feature that can be enabled on developer, test, or preprod environments and

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-02 18:36 GMT+01:00 Jim Nasby : > On 1/1/17 12:17 PM, Pavel Stehule wrote: > >> I wrote some initial patch >> >> Do you think so has sense to continue in this topic? >> > > Perhaps I'm not understanding what plpgsql_extra_errors does, but I don't > think either of

Re: [HACKERS] merging some features from plpgsql2 project

On 1/1/17 12:17 PM, Pavel Stehule wrote: I wrote some initial patch Do you think so has sense to continue in this topic? Perhaps I'm not understanding what plpgsql_extra_errors does, but I don't think either of these should depend on that being true. IMO these two checks should be default

Re: [HACKERS] merging some features from plpgsql2 project

Hi I wrote some initial patch Do you think so has sense to continue in this topic? Regards Pavel diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c index 77e7440..15b867fa 100644 --- a/src/pl/plpgsql/src/pl_exec.c +++ b/src/pl/plpgsql/src/pl_exec.c @@ -3616,6 +3616,24 @@

Re: [HACKERS] merging some features from plpgsql2 project

2016-12-28 20:25 GMT+01:00 Jim Nasby : > On 12/28/16 12:51 PM, Pavel Stehule wrote: > >> Now, the incompatibility can be hard issue - it is big question if we >> lock some users on old versions because some users can save to lines of >> code. Introduction of ROW_COUNT is

Re: [HACKERS] merging some features from plpgsql2 project

On 12/28/16 12:51 PM, Pavel Stehule wrote: Now, the incompatibility can be hard issue - it is big question if we lock some users on old versions because some users can save to lines of code. Introduction of ROW_COUNT is lowly incompatibility - it can be simply detected - but for example change

Re: [HACKERS] merging some features from plpgsql2 project

2016-12-28 18:54 GMT+01:00 Jim Nasby : > On 12/28/16 7:16 AM, Pavel Stehule wrote: > >> >> >> 2016-12-28 5:09 GMT+01:00 Jim Nasby > >: >> >> On 12/27/16 4:56 PM, Merlin Moncure wrote: >> >> On Tue,

Re: [HACKERS] merging some features from plpgsql2 project

2016-12-28 19:23 GMT+01:00 Jim Nasby : > On 12/28/16 12:15 PM, Pavel Stehule wrote: > >> GUC are fragile - the source code and settings can be separated. >> > > *Can* be, but they don't *have* to be. That's a huge feature, not a bug. > > Our #option is more robust,

Re: [HACKERS] merging some features from plpgsql2 project

On 12/28/16 12:15 PM, Pavel Stehule wrote: GUC are fragile - the source code and settings can be separated. *Can* be, but they don't *have* to be. That's a huge feature, not a bug. Our #option is more robust, because source code holds all flags required for execution. So I would to see a

Re: [HACKERS] merging some features from plpgsql2 project

2016-12-28 18:54 GMT+01:00 Jim Nasby : > On 12/28/16 7:16 AM, Pavel Stehule wrote: > >> ** The real problem is that we have no mechanism for allowing a PL's >> language/syntax/API to move forward without massive backwards >> compatibility problems. ** >> >>

Re: [HACKERS] merging some features from plpgsql2 project

On 12/28/16 7:16 AM, Pavel Stehule wrote: 2016-12-28 5:09 GMT+01:00 Jim Nasby >: On 12/27/16 4:56 PM, Merlin Moncure wrote: On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule

Re: [HACKERS] merging some features from plpgsql2 project

On 12/28/16 7:16 AM, Pavel Stehule wrote: ** The real problem is that we have no mechanism for allowing a PL's language/syntax/API to move forward without massive backwards compatibility problems. ** We have not, but there are few possibilities: 1. enhance #option command 2. we

Re: [HACKERS] merging some features from plpgsql2 project

2016-12-28 5:09 GMT+01:00 Jim Nasby : > On 12/27/16 4:56 PM, Merlin Moncure wrote: > >> On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule >> wrote: >> >>> First I describe my initial position. I am strongly against introduction >>> "new" language -

Re: [HACKERS] merging some features from plpgsql2 project

On 12/27/16 4:56 PM, Merlin Moncure wrote: On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule wrote: First I describe my initial position. I am strongly against introduction "new" language - plpgsql2 or new plpgsql, or any else. The trust of developers to us is important

Re: [HACKERS] merging some features from plpgsql2 project

2016-12-27 23:56 GMT+01:00 Merlin Moncure : > On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule > wrote: > > Hi > > > > I reread ideas described on page https://github.com/trustly/plpgsql2 > > > > Some points are well and can be benefit for PlpgSQL. > >

Re: [HACKERS] merging some features from plpgsql2 project

On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule wrote: > Hi > > I reread ideas described on page https://github.com/trustly/plpgsql2 > > Some points are well and can be benefit for PlpgSQL. > > First I describe my initial position. I am strongly against introduction >

Re: [HACKERS] merging some features from plpgsql2 project

2016-12-27 8:54 GMT+01:00 Pavel Stehule : > Hi > > I reread ideas described on page https://github.com/trustly/plpgsql2 > > Some points are well and can be benefit for PlpgSQL. > > First I describe my initial position. I am strongly against introduction > "new" language -