PL/pgSQL 2
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 theory. Even though you own code would survive the change, there
might be code somewhere in the world which would break. This is of course
not acceptable and that's why we have the current status quo of
development, or at least not far away from a status quo.
So instead of continue to adding optional settings to the config file, and
instead of killing discussions around what can be done by bringing up the
backwards-compatibility argument, let's instead fork the language and call
it plpgsql2. Since no code is yet written in plpgsql2, we can start of from
a clean sheet, and no good ideas need to be killed due to
backwards-compatibility concerns.
The interest for such a project is probably limited to a small number of
companies/people around the world, as most users are probably perfectly
happy with the current version of plpgsql, as they only use it occasionally
and not every day like we do at my company.
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.
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 provide alternative syntax to
modify multiple or zero rows.
+ Make SELECT .. INTO .. throw an error if it selects more than 1 row. INTO
STRICT only works if no rows should be an error, but there is currently no
nice way if no rows OR exactly 1 row should be found by the query.
+ Change all warnings into errorsThese are small changes, probably possible with just a few hundred lines of
code in total, which also should be the ambition, as larger changes would
never survive during time as it would require too much efforts to keep up
with the main project. Secondly, I trust plpgsql mainly because it's being
used by a lot of people in a lot of production systems, the same would not
hold true for plpgsql2 for the first years of existence, so we who would
use it in production systems must understand every single line of code
changed and feel the risk of possible bugs and their impact are within
acceptable boundaries.
I can probably think of a few more things, but these are the major
annoyances.
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.
Regards, Joel
On 2014-09-01 11:04:53 +0200, Joel Jacobson wrote:
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 theory. Even though you own code would survive the change, there
might be code somewhere in the world which would break. This is of course
not acceptable and that's why we have the current status quo of
development, or at least not far away from a status quo.So instead of continue to adding optional settings to the config file, and
instead of killing discussions around what can be done by bringing up the
backwards-compatibility argument, let's instead fork the language and call
it plpgsql2. Since no code is yet written in plpgsql2, we can start of from
a clean sheet, and no good ideas need to be killed due to
backwards-compatibility concerns.The interest for such a project is probably limited to a small number of
companies/people around the world, as most users are probably perfectly
happy with the current version of plpgsql, as they only use it occasionally
and not every day like we do at my company.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.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 provide alternative syntax to modify multiple or zero rows. + Make SELECT .. INTO .. throw an error if it selects more than 1 row. INTO STRICT only works if no rows should be an error, but there is currently no nice way if no rows OR exactly 1 row should be found by the query. + Change all warnings into errors
-many.
Look at the *disaster* the few minor changes in python3 were. It's now,
years after, only starting to get used again.
You're going to have to find a more gradual way of doing this.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/01/2014 11:24 AM, Andres Freund wrote:
On 2014-09-01 11:04:53 +0200, Joel Jacobson wrote:
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 theory. Even though you own code would survive the change, there
might be code somewhere in the world which would break. This is of course
not acceptable and that's why we have the current status quo of
development, or at least not far away from a status quo.So instead of continue to adding optional settings to the config file, and
instead of killing discussions around what can be done by bringing up the
backwards-compatibility argument, let's instead fork the language and call
it plpgsql2. Since no code is yet written in plpgsql2, we can start of from
a clean sheet, and no good ideas need to be killed due to
backwards-compatibility concerns.The interest for such a project is probably limited to a small number of
companies/people around the world, as most users are probably perfectly
happy with the current version of plpgsql, as they only use it occasionally
and not every day like we do at my company.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.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 provide alternative syntax to modify multiple or zero rows. + Make SELECT .. INTO .. throw an error if it selects more than 1 row. INTO STRICT only works if no rows should be an error, but there is currently no nice way if no rows OR exactly 1 row should be found by the query. + Change all warnings into errors-many.
Look at the *disaster* the few minor changes in python3 were. It's now,
years after, only starting to get used again.You're going to have to find a more gradual way of doing this.
Probably a better way (and there has been some talk of it) is
having some kind of PRAGMA functionality, or pl/pgsql specific
LOCAL SET to affect "just this function" and not spill to nested
functions as is the case for SETs now.
Cheers
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic O�
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 9/1/14 11:53 AM, Hannu Krosing wrote:
On 09/01/2014 11:24 AM, Andres Freund wrote:
Look at the *disaster* the few minor changes in python3 were. It's now,
years after, only starting to get used again.You're going to have to find a more gradual way of doing this.
Probably a better way (and there has been some talk of it) is
having some kind of PRAGMA functionality, or pl/pgsql specific
LOCAL SET to affect "just this function" and not spill to nested
functions as is the case for SETs now.
I can't imagine how that would work for anyone who has thousands of
functions.
I've tried my best over the past ~year or so, but any attempts at
breaking backwards compatibility have been rejected. I really don't see
any gradual way of doing this. We either break things, live with what
we have right now, or create a new language.
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Sep 1, 2014 at 11:24 AM, Andres Freund <andres@2ndquadrant.com> wrote:
-many.
Look at the *disaster* the few minor changes in python3 were. It's now,
years after, only starting to get used again.You're going to have to find a more gradual way of doing this.
I agree this is a valid concern, and is also something I've taken into
account already.
The things I would like to see change, won't break any of my own code,
and probably not much of others either.
Let's examine my list and see what impact if would have to modern
plpgsql code written according to best practices:
+ 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.
If you application already aims to modify 1 row exactly at most places
in the code where you have UPDATE/INSERT/DELETE,
then making that the default behaviour of the default syntax would be
an improvement, as you wouldn't need special syntax for the default
use-case.
Instead, by providing a way to do the less common use-case of
modifying <>1 row, using an alternative way, we make it possible to
rewrite any existing code.
The amount of code we need to rewrite is minimized by optimizing the
syntax for the most common use-case.
+ Make SELECT .. INTO .. throw an error if it selects more than 1 row. INTO
STRICT only works if no rows should be an error, but there is currently no
nice way if no rows OR exactly 1 row should be found by the query.
This wouldn't have any impact for most applications, except when
things go wrong, and if the query *would* return more than 1 row you
probably want an error to be thrown, that's the most common use-case.
By making it necessary to explicity say you are OK with more than 1
row, we again optimize the syntax for the most common use-case, but
provide an alternative way of allowing the corner-case.
+ Change all warnings into errors
The warnings should of course be errors, if we wouldn't need to worry
about legacy code, which we don't with plpgsql2.
In summary, if you write new code, it will work without any changes in
most of the cases, and in the cases where you need to change it, there
is a very good valid reason why you want to do that anyway, as the
alternative is either insecure or ugly.
Also, a stricter language with fewer alternative obsolete syntax
variations and optional settings means the lines of code and the
complexity can be reduced.
Compared with the changes in python3, the changes between python2 and
python3 *did* break compatibility and all code had to be rewritten. In
contrast, most plpgsql functions won't need to be rewritten, only a
few of them will need to be rewritten, which is acceptable.
Another difference when comparing it to python3 is the possibility to
mix plpgsql and plpgsql2 functions within the same system. With
python3, you can't use existing python2 modules, but new plpgsql2
functions can of course call any existing plpgsql functions.
The "gradual way" of doing this is to add plpgsql2, and then write all
new code in the language, and then port function by function from
plpgsql to plpgsql2, without any deadlines.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-09-01 12:00:48 +0200, Marko Tiikkaja wrote:
On 9/1/14 11:53 AM, Hannu Krosing wrote:
You're going to have to find a more gradual way of doing this.
Probably a better way (and there has been some talk of it) is
having some kind of PRAGMA functionality, or pl/pgsql specific
LOCAL SET to affect "just this function" and not spill to nested
functions as is the case for SETs now.I can't imagine how that would work for anyone who has thousands of
functions.
How's that fundamentally different from changing languages? If we had a
way to *add* such attributes to *existing* functions I don't see the
fundamental problem?
I've tried my best over the past ~year or so, but any attempts at breaking
backwards compatibility have been rejected. I really don't see any gradual
way of doing this. We either break things, live with what we have right
now, or create a new language.
I think to some degree that was also influenced by the approach you
took. Several of the changes didn't really have a meaningful explanation
why they'd be helpful in the field. I.e. the change was explained, but
not the reasoning *leading* to the change and which other solutions you
thought about.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/01/2014 12:00 PM, Marko Tiikkaja wrote:
On 9/1/14 11:53 AM, Hannu Krosing wrote:
On 09/01/2014 11:24 AM, Andres Freund wrote:
Look at the *disaster* the few minor changes in python3 were. It's now,
years after, only starting to get used again.You're going to have to find a more gradual way of doing this.
Probably a better way (and there has been some talk of it) is
having some kind of PRAGMA functionality, or pl/pgsql specific
LOCAL SET to affect "just this function" and not spill to nested
functions as is the case for SETs now.I can't imagine how that would work for anyone who has thousands of
functions.I've tried my best over the past ~year or so, but any attempts at
breaking backwards compatibility have been rejected. I really don't
see any gradual way of doing this. We either break things, live with
what we have right now, or create a new language..marko
My approach would be to add optional LOCAL modifier to WITH, so instead
CREATE [ OR REPLACE ] FUNCTION
name ( [ [ argmode ] [ argname ] argtype [ { DEFAULT | = }
default_expr ] [, ...] ] )
...
[ WITH ( attribute [, ...] ) ]
it would be
...
[ WITH ( [LOCAL] attribute [, ...] ) ]
where LOCAL attributes are _not_ inherited by nested functions
but the LOCALs would shadow globals in the function definitions
that have them.
I know it is easier said than done, but from the user perspective
this could be a nice clean approach.
Cheers
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic O�
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Sep 1, 2014 at 12:32 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote:
it would be
...
[ WITH ( [LOCAL] attribute [, ...] ) ]where LOCAL attributes are _not_ inherited by nested functions
but the LOCALs would shadow globals in the function definitions
that have them.I know it is easier said than done, but from the user perspective
this could be a nice clean approach.
Drawbacks of that approach are mainly you would need to specify a lot
of attributes for newly written functions to get the behaviour you
want, and it also won't reduce the complexity of the language, rather
the contrary, the more settings and the more alternative ways of doing
things, the more complex will the implementation of the language
become. This is why postgresql is surperiour to for instance mysql, as
with mysql you need to set a lot of obscure settings to get the
desired behaviour, like making 2014-03-31 an error instead of allow
the invalid value. I wish plpgsql was just like postgresql, a very
strict language.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 9/1/14 12:12 PM, Andres Freund wrote:
On 2014-09-01 12:00:48 +0200, Marko Tiikkaja wrote:
On 9/1/14 11:53 AM, Hannu Krosing wrote:
You're going to have to find a more gradual way of doing this.
Probably a better way (and there has been some talk of it) is
having some kind of PRAGMA functionality, or pl/pgsql specific
LOCAL SET to affect "just this function" and not spill to nested
functions as is the case for SETs now.I can't imagine how that would work for anyone who has thousands of
functions.How's that fundamentally different from changing languages? If we had a
way to *add* such attributes to *existing* functions I don't see the
fundamental problem?
Adding 5-10 of these for every function you create seems significantly
more painful than saying "this function uses plpgsql2". Though perhaps
what's being suggested is a *single* option which changes everything at
once? Then there wouldn't be a huge difference.
I've tried my best over the past ~year or so, but any attempts at breaking
backwards compatibility have been rejected. I really don't see any gradual
way of doing this. We either break things, live with what we have right
now, or create a new language.I think to some degree that was also influenced by the approach you
took. Several of the changes didn't really have a meaningful explanation
why they'd be helpful in the field. I.e. the change was explained, but
not the reasoning *leading* to the change and which other solutions you
thought about.
Yes, I agree I didn't always do a terrific job (see: EXIT USING
ROLLBACK), but some of them have been outright rejected even though
people clearly saw the value (I would put ASSERT into that category, and
the change to SELECT .. INTO obviously belongs here).
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/01/2014 05:24 PM, Andres Freund wrote:
Look at the *disaster* the few minor changes in python3 were. It's now,
years after, only starting to get used again.
While that's valid, I'd like to point out that Python2 and Python3 don't
share a runtime and can't easily use each others' modules and functions.
The difference with any "plpgsql2" is that it'd live within the same
runtime - PostgreSQL - as plpgsql and the other languages, and would
share the same interfaces.
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/replace member functions, even hot-patch bytecode. That's not
something we allow in PL/PgSQL, though; from the outside a PL/PgSQL
function is pretty opaque to callers.
That's not to say I'm keen on a "plpgsql2" unless there's no other way;
I'd be rather happier with language version pragmas or similar. But I
don't think it's analogous to Python2 vs Python3.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-09-01 12:49:22 +0200, Marko Tiikkaja wrote:
On 9/1/14 12:12 PM, Andres Freund wrote:
On 2014-09-01 12:00:48 +0200, Marko Tiikkaja wrote:
On 9/1/14 11:53 AM, Hannu Krosing wrote:
You're going to have to find a more gradual way of doing this.
Probably a better way (and there has been some talk of it) is
having some kind of PRAGMA functionality, or pl/pgsql specific
LOCAL SET to affect "just this function" and not spill to nested
functions as is the case for SETs now.I can't imagine how that would work for anyone who has thousands of
functions.How's that fundamentally different from changing languages? If we had a
way to *add* such attributes to *existing* functions I don't see the
fundamental problem?Adding 5-10 of these for every function you create seems significantly more
painful than saying "this function uses plpgsql2". Though perhaps what's
being suggested is a *single* option which changes everything at once? Then
there wouldn't be a huge difference.
The likelihood of us now knowing all the things that we want to break
rigth now seems about zero. There *will* be further ones. If we go with
the approach of creating new language versions for all of them we'll end
up with a completely unmaintainable mess. For PG devs, application dev
and DBAs.
Since what you seemingly want - sensibly so imo - is to set the default
errors for *new* functions, but leave the old set of errors for
preexisting ones, I suggest adding a GUC that defines the set of
warnings/errors *new* functions get. There'd need to be some syntax to
opt out for pg_dump and similar, but that sounds unproblematic.
One question here imo is whether we design something for plpgsql or more
generic...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi
2014-09-01 11:04 GMT+02:00 Joel Jacobson <joel@trustly.com>:
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 theory. Even though you own code would survive the change,
there might be code somewhere in the world which would break. This is of
course not acceptable and that's why we have the current status quo of
development, or at least not far away from a status quo.So instead of continue to adding optional settings to the config file,
and instead of killing discussions around what can be done by bringing up
the backwards-compatibility argument, let's instead fork the language and
call it plpgsql2. Since no code is yet written in plpgsql2, we can start of
from a clean sheet, and no good ideas need to be killed due to
backwards-compatibility concerns.The interest for such a project is probably limited to a small number of
companies/people around the world, as most users are probably perfectly
happy with the current version of plpgsql, as they only use it
occasionally and not every day like we do at my company.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.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 provide alternative syntax to modify multiple or zero rows. + Make SELECT .. INTO .. throw an error if it selects more than 1 row. INTO STRICT only works if no rows should be an error, but there is currently no nice way if no rows OR exactly 1 row should be found by the query. + Change all warnings into errorsThese are small changes, probably possible with just a few hundred lines
of code in total, which also should be the ambition, as larger changes
would never survive during time as it would require too much efforts to
keep up with the main project. Secondly, I trust plpgsql mainly because
it's being used by a lot of people in a lot of production systems, the same
would not hold true for plpgsql2 for the first years of existence, so we
who would use it in production systems must understand every single line of
code changed and feel the risk of possible bugs and their impact are within
acceptable boundaries.I can probably think of a few more things, but these are the major
annoyances.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.
I agree with Andres - it is not a good for plpgsql and for plpgsql users.
The benefit must be significant for 90% of users.
Almost all from your mentioned issue can be solved by some extensions with
some new hooks. I don't agree, so UPDATE/INSERT/DELETE should to work only
with one row.
What I dislike on plpgsql:
* manipulation with expressions
* supply lot of SPI API in plpgsql
* inconsistent internal casting to target / returned values
* missing internal API for more stricter / smarted validation
* strange week implementation of left part of assign statement
* sometimes strange work with composite types
* late IO casting
on second hand it is fast practical language.
Official implementation of plpgsql2 can be very wrong and dangerous signal
- so we should not to do.
My plan .. maybe too long
enhancing SPI to better expression support
new PL API for support variables stack and handling variables
new API with communication with gdb
============================================
implementation of SQL/PSM .. it is new language .. based on relative good
ANSI SQL specification without compatibility issues
reimplementation plpgsql based on new API .. it should to significantly
reduce size
otherwise plpgsql2 is wrong name .. with respect to your goals it should be
"stricter plpgsql"
Regards
Pavel
Show quoted text
Regards, Joel
On Mon, Sep 1, 2014 at 12:55 PM, Andres Freund <andres@2ndquadrant.com> wrote:
The likelihood of us now knowing all the things that we want to break
rigth now seems about zero. There *will* be further ones. If we go with
the approach of creating new language versions for all of them we'll end
up with a completely unmaintainable mess. For PG devs, application dev
and DBAs.
PL/pgSQL was added in 1998 (16 years ago).
Compared this with again Python:
1994 Python 1.0
2000 Python 2.0 (6 years later)
2008 Python 3.0 (8 years later)
Of course we don't know all the things we want to break in the *future*,
but there is a good chance all users of PL/pgSQL know what they want
to change *today*,
thanks to the 16 years of active development in the language.
In 16 years from now, maybe there is a need for PL/pgSQL 3, or maybe
not, who knows.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2014-09-01 13:30 GMT+02:00 Joel Jacobson <joel@trustly.com>:
On Mon, Sep 1, 2014 at 12:55 PM, Andres Freund <andres@2ndquadrant.com>
wrote:The likelihood of us now knowing all the things that we want to break
rigth now seems about zero. There *will* be further ones. If we go with
the approach of creating new language versions for all of them we'll end
up with a completely unmaintainable mess. For PG devs, application dev
and DBAs.PL/pgSQL was added in 1998 (16 years ago).
Compared this with again Python:
1994 Python 1.0
2000 Python 2.0 (6 years later)
2008 Python 3.0 (8 years later)Of course we don't know all the things we want to break in the *future*,
but there is a good chance all users of PL/pgSQL know what they want
to change *today*,
thanks to the 16 years of active development in the language.In 16 years from now, maybe there is a need for PL/pgSQL 3, or maybe
not, who knows.
For lot of people is Python3 big fail - and it can be much more dangerous
for Postgres than for much more larger Python community.
I don't see a necessity to do again. I have very good knowledge about users
in Czech, and probably only I know a limits of plpgsql.
I am thinking so some enhancing of plpgsql (extensions, extra errors, extra
warnings) is possible.
Regards
Pavel
Show quoted text
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule <pavel.stehule@gmail.com> 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 signal -
so we should not to do.
Do you argue the introduction of plpgsql2 would hurt the users of
plpgsql in some way? How?
If you have X% who continue to happily use plpgsql, and (100-X%) who
find they can use plpgsql2 in their project, for new functions or all
functions (for a new project), then you have made (100-X)% of the
users more happy, than they would be if they were forced to use
plpgsql and suffer from its problems.
It *would* be a problem if you had to choose between writing all
functions in their plpgsql or plpgsql2, but thanks to postgres support
for different pl-languages and mixing different languages in the same
project, I cannot see the problem.
implementation of SQL/PSM .. it is new language .. based on relative good
ANSI SQL specification without compatibility issues
reimplementation plpgsql based on new API .. it should to significantly
reduce size
A new language like SQL/PSM would be helpful for new projects,
but personally I have a huge code base written in plpgsql which
I would at some point want to port to plpgsql2, and the least time consuming
way of doing so would be to make sure most existing plpgsql-functions
require no modifications at all to work with plpgsql2.
A new language would mean I would have to rewrite all functions,
which is much worse than doing no or minor modifications to existing functions.
otherwise plpgsql2 is wrong name .. with respect to your goals it should be
"stricter plpgsql"
I think plpgsql2 is a perfect name for it, because it is a new version
of plpgsql,
based on all the empirical knowledge gained from the 16 years of
development in plpgsql.
And while most improvements fall in the "stricter" category, there are
probably other things
which we would want to change when having the possibility of breaking
compatibility.
I think the main difference in what is possible with plpgsql2 compared
to improvements of plpgsql,
boil down to not having to evaluate any proposed change against "could
this break compatibility in theory?"
but instead "will this most certainly break compatilibity for most users?".
Today, if a proposed code change in plpgsql would have an impact >0%,
the change is rejected.
With plpgsql2, maybe we could allow an impact of <X% of lines of code.
If greater than X%, users will think it's unrealistic to port all
their code from plpgsql to plpgsql2,
which might be a long-term realistic requirement for some users,
especially for the project,
as in Y years from now, maybe the development of plpgsql can be put to halt,
to avoid having to maintain both code bases, which *is* undoubtably an
increased workload for the project.
Also, all your work and effort with plpgsql_check_function() would be
a natural fit for plpgsql2,
the problems it detect should of course be errors by default in the language.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2014-09-01 14:27 GMT+02:00 Joel Jacobson <joel@trustly.com>:
On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule <pavel.stehule@gmail.com>
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
signal -
so we should not to do.
Do you argue the introduction of plpgsql2 would hurt the users of
plpgsql in some way? How?
yes, anybody who has thousands lines in plpgsql will be messy, when we
publish so there will be new not fully compatible plpgsql2.
If you have X% who continue to happily use plpgsql, and (100-X%) who
find they can use plpgsql2 in their project, for new functions or all
functions (for a new project), then you have made (100-X)% of the
users more happy, than they would be if they were forced to use
plpgsql and suffer from its problems.
It bad signal to have two languages plpgsql and plpgsql2. Who will believe
to us so we will continue development of plpgsql?
It *would* be a problem if you had to choose between writing all
functions in their plpgsql or plpgsql2, but thanks to postgres support
for different pl-languages and mixing different languages in the same
project, I cannot see the problem.implementation of SQL/PSM .. it is new language .. based on relative good
ANSI SQL specification without compatibility issues
reimplementation plpgsql based on new API .. it should to significantly
reduce sizeA new language like SQL/PSM would be helpful for new projects,
but personally I have a huge code base written in plpgsql which
I would at some point want to port to plpgsql2, and the least time
consuming
way of doing so would be to make sure most existing plpgsql-functions
require no modifications at all to work with plpgsql2.
I understand - just I don't would to repeat a issues of Python3 or Perl6 or
..
I don't believe so people understand different casting rules in almost all
same language plpgsql and plpgsql2. So it is one reason why start from zero
with less know syntax.
More I don't feel a real request from users.
A new language would mean I would have to rewrite all functions,
which is much worse than doing no or minor modifications to existing
functions.otherwise plpgsql2 is wrong name .. with respect to your goals it should
be
"stricter plpgsql"
I think plpgsql2 is a perfect name for it, because it is a new version
of plpgsql,
based on all the empirical knowledge gained from the 16 years of
development in plpgsql.
And while most improvements fall in the "stricter" category, there are
probably other things
which we would want to change when having the possibility of breaking
compatibility.
you can do it - but will be better as independent project.
There is big space for improvement in plpgsql - but almost all can be done
without some stronger incompatibility.
Or this incompatibility (or stronger restrictivity) can be introduced in
longer time window.
I think the main difference in what is possible with plpgsql2 compared
to improvements of plpgsql,
boil down to not having to evaluate any proposed change against "could
this break compatibility in theory?"
but instead "will this most certainly break compatilibity for most users?".Today, if a proposed code change in plpgsql would have an impact >0%,
the change is rejected.
because it was useless - it was not any new value.
With plpgsql2, maybe we could allow an impact of <X% of lines of code.
If greater than X%, users will think it's unrealistic to port all
their code from plpgsql to plpgsql2,
which might be a long-term realistic requirement for some users,
especially for the project,
as in Y years from now, maybe the development of plpgsql can be put to
halt,
to avoid having to maintain both code bases, which *is* undoubtably an
increased workload for the project.Also, all your work and effort with plpgsql_check_function() would be
a natural fit for plpgsql2,
the problems it detect should of course be errors by default in the
language.
plpgsql_check is necessary because we don't would to introduce strong
dependency between functions and database schema. It is 70% motivation.
Next 30% can be integrated to language well. And I believe if PL engine was
more friendly to extensions, it can be 80% less code.
Pavel
On 09/01/2014 12:55 PM, Andres Freund wrote:
On 2014-09-01 12:49:22 +0200, Marko Tiikkaja wrote:
On 9/1/14 12:12 PM, Andres Freund wrote:
On 2014-09-01 12:00:48 +0200, Marko Tiikkaja wrote:
On 9/1/14 11:53 AM, Hannu Krosing wrote:
You're going to have to find a more gradual way of doing this.
Probably a better way (and there has been some talk of it) is
having some kind of PRAGMA functionality, or pl/pgsql specific
LOCAL SET to affect "just this function" and not spill to nested
functions as is the case for SETs now.I can't imagine how that would work for anyone who has thousands of
functions.How's that fundamentally different from changing languages? If we had a
way to *add* such attributes to *existing* functions I don't see the
fundamental problem?Adding 5-10 of these for every function you create seems significantly more
painful than saying "this function uses plpgsql2".
You could package up these 5-10 SET LOCAL options as a separate language
handler (called plpgsql2) which really does nothing more than set the
local options and call the base handler :)
this will still leave you with flexibility of adding/removing features for
single functions
For extra convenience you could even create a "CREATE META LANGUAGE ..."
option for defining such language handlers.
Though perhaps what's
being suggested is a *single* option which changes everything at once? Then
there wouldn't be a huge difference.The likelihood of us now knowing all the things that we want to break
rigth now seems about zero. There *will* be further ones. If we go with
the approach of creating new language versions for all of them we'll end
up with a completely unmaintainable mess. For PG devs, application dev
and DBAs.Since what you seemingly want - sensibly so imo - is to set the default
errors for *new* functions, but leave the old set of errors for
preexisting ones, I suggest adding a GUC that defines the set of
warnings/errors *new* functions get. There'd need to be some syntax to
opt out for pg_dump and similar, but that sounds unproblematic.One question here imo is whether we design something for plpgsql or more
generic...
I for one would like to have a generic "SET LOCAL" feature so it
could also be used for pl/pythonu or pl/v8
Cheers
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic O�
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 9/1/14 2:53 PM, Pavel Stehule wrote:
2014-09-01 14:27 GMT+02:00 Joel Jacobson <joel@trustly.com>:
On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule <pavel.stehule@gmail.com>
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
signal -
so we should not to do.
Do you argue the introduction of plpgsql2 would hurt the users of
plpgsql in some way? How?yes, anybody who has thousands lines in plpgsql will be messy, when we
publish so there will be new not fully compatible plpgsql2.
That's a good thing. PL/PgSQL is broken in various subtle ways.
If you have X% who continue to happily use plpgsql, and (100-X%) who
find they can use plpgsql2 in their project, for new functions or all
functions (for a new project), then you have made (100-X)% of the
users more happy, than they would be if they were forced to use
plpgsql and suffer from its problems.It bad signal to have two languages plpgsql and plpgsql2. Who will believe
to us so we will continue development of plpgsql?
I think what should happen is that we stop adding features to plpgsql.
We should design plpgsql2 in such a way that it's easier to add new
features to it in the future (to the extent that that's possible), and
then add the new stuff only to that one.
A new language like SQL/PSM would be helpful for new projects,
but personally I have a huge code base written in plpgsql which
I would at some point want to port to plpgsql2, and the least time
consuming
way of doing so would be to make sure most existing plpgsql-functions
require no modifications at all to work with plpgsql2.I understand - just I don't would to repeat a issues of Python3 or Perl6 or
..I don't believe so people understand different casting rules in almost all
same language plpgsql and plpgsql2. So it is one reason why start from zero
with less know syntax.
I'm not convinced. Seems to me that it would be better in every way to
just fix the familiar syntax.
More I don't feel a real request from users.
Yeah, that's the problem with subtle problems: only people who use the
language a lot and pay attention are going to notice them.
A new language would mean I would have to rewrite all functions,
which is much worse than doing no or minor modifications to existing
functions.otherwise plpgsql2 is wrong name .. with respect to your goals it should
be
"stricter plpgsql"
I think plpgsql2 is a perfect name for it, because it is a new version
of plpgsql,
based on all the empirical knowledge gained from the 16 years of
development in plpgsql.
And while most improvements fall in the "stricter" category, there are
probably other things
which we would want to change when having the possibility of breaking
compatibility.you can do it - but will be better as independent project.
There is big space for improvement in plpgsql - but almost all can be done
without some stronger incompatibility.
That's very very general and it would depend on the details, but I still
disagree in general.
Or this incompatibility (or stronger restrictivity) can be introduced in
longer time window.
I'd think that that would be worse for the current users of PL/PgSQL,
not better.
If greater than X%, users will think it's unrealistic to port all
their code from plpgsql to plpgsql2,
which might be a long-term realistic requirement for some users,
especially for the project,
as in Y years from now, maybe the development of plpgsql can be put to
halt,
to avoid having to maintain both code bases, which *is* undoubtably an
increased workload for the project.Also, all your work and effort with plpgsql_check_function() would be
a natural fit for plpgsql2,
the problems it detect should of course be errors by default in the
language.plpgsql_check is necessary because we don't would to introduce strong
dependency between functions and database schema. It is 70% motivation.Next 30% can be integrated to language well. And I believe if PL engine was
more friendly to extensions, it can be 80% less code.
Yeah, PL/PgSQL is a bit hostile to to extensions like plpgsql_check.
But that doesn't mean that we have to bin everything we have and start
from scratch.
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule <pavel.stehule@gmail.com> 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 "development".
Bugfixes of plpgsql? Yes, of course.
New features? No, but that's a non-issue since we all know it's more
or less impossible to introduce new features without breaking
compatibility, I think you will agree on that, no?
A new language like SQL/PSM would be helpful for new projects,
but personally I have a huge code base written in plpgsql which
I would at some point want to port to plpgsql2, and the least time
consuming
way of doing so would be to make sure most existing plpgsql-functions
require no modifications at all to work with plpgsql2.I understand - just I don't would to repeat a issues of Python3 or Perl6 or
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.
I think plpgsql2 is a perfect name for it, because it is a new version
of plpgsql,
based on all the empirical knowledge gained from the 16 years of
development in plpgsql.
And while most improvements fall in the "stricter" category, there are
probably other things
which we would want to change when having the possibility of breaking
compatibility.you can do it - but will be better as independent project.
There is big space for improvement in plpgsql - but almost all can be done
without some stronger incompatibility.Or this incompatibility (or stronger restrictivity) can be introduced in
longer time window.
With "can be done" you have to take into account what kind of changes
the project accepts into the plpgsql-code
Looking back a few years of efforts from people (including yourself),
it looks like much of the energy and hours invested would have made a
much better pay-off in a new language.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-09-01 15:19:41 +0200, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule <pavel.stehule@gmail.com> 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 "development".
Bugfixes of plpgsql? Yes, of course.
New features? No, but that's a non-issue since we all know it's more
or less impossible to introduce new features without breaking
compatibility, I think you will agree on that, no?
Sorry, but that's just plain wrong. There've been plenty of new features
for plpgsql. You're not very convincing if you use bogus arguments like
this.
EOD for me.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
