On Mon, 1 Sep 2014 15:19:41 +0200
Joel Jacobson j...@trustly.com wrote:
The fatal problems with Python3 and Perl6 was the inability to mix
code between Python2/3 and Perl5/6.
We don't have that problem with pl-languages in postgres, so please
don't make that comparison, as it's incorrect.
2014-09-04 18:29 GMT-03:00 Robert Haas robertmh...@gmail.com:
On Thu, Sep 4, 2014 at 2:31 PM, Josh Berkus j...@agliodbs.com wrote:
Sadly, what's prevented us from having packages already has been the
insistence of potential feature sponsors that they work *exactly* like
PL/SQL's packages,
On Tue, Oct 7, 2014 at 12:42 PM, Steven Lembark lemb...@wrkhors.com wrote:
On Mon, 1 Sep 2014 15:19:41 +0200
Joel Jacobson j...@trustly.com wrote:
The fatal problems with Python3 and Perl6 was the inability to mix
code between Python2/3 and Perl5/6.
We don't have that problem with
On 10/7/14, 1:08 PM, Rodolfo Campero wrote:
If it were possible to mark a function as private for its extension that
would be awesome (the opposite would work too, i.e. a way to specify a public API,
meaning the rest is private). For big extensions it's not clear which functions can be
used
On Mon, 01 Sep 2014 12:00:48 +0200
Marko Tiikkaja ma...@joh.to wrote:
create a new language.
There are enough problems with SQL in general, enough alternatives
proposed over time that it might be worth coming up with something
that Just Works.
--
Steven Lembark
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
On 04/09/14 18:02, Craig Ringer wrote:
On 09/04/2014 06:48 AM, Joshua D. Drake wrote:
On 09/03/2014 11:48 AM, Robert Haas wrote:
Anyway, to get back around to the topic of PL/SQL compatibility
specifically, if you care about that issue, pick one thing that exists
in PL/SQL but not in
On 03/09/14 20:48, Robert Haas wrote:
On Tue, Sep 2, 2014 at 5:47 PM, Álvaro Hernández Tortosa a...@nosys.es wrote:
Yeah, we differ there. I think having an Oracle compatibility layer in
PostgreSQL would be the-next-big-thing we could have. Oracle is has orders
of magnitude bigger user
On Fri, Sep 5, 2014 at 6:18 PM, Andrew Dunstan and...@dunslane.net wrote:
On 09/05/2014 12:37 PM, Merlin Moncure wrote:
On Thu, Sep 4, 2014 at 6:40 PM, Florian Pflug f...@phlo.org wrote:
Cost of hidden IO cast is negative too. If we can change it, then we can
increase a sped.
But the
On 09/05/2014 10:32 PM, Marko Tiikkaja wrote:
On 2014-09-02 8:52 PM, Kevin Grittner wrote:
Marko Tiikkaja ma...@joh.to wrote:
Sounds like in this case you'd only use set-oriented programming
at the end of the transaction, no?
I guess -- more properly I would say in the final database
On 2014-09-06 6:06 PM, Jan Wieck wrote:
You can dismiss what we're doing by saying that it doesn't follow the
best practices or we just want an interface for a key-value store or
whatever. And yes, to some extent, a simple interface for a key-value
store would come in handy. But we still have
On 09/06/2014 12:17 PM, Marko Tiikkaja wrote:
OK, fine. But that's not what I suggested on the wiki page, and is also
not what I'm arguing for here right now. What the message you referred
to was about was the condescending attitude where we were told to think
in terms of sets (paraphrased),
On 2014-09-06 6:31 PM, Jan Wieck wrote:
On 09/06/2014 12:17 PM, Marko Tiikkaja wrote:
OK, fine. But that's not what I suggested on the wiki page, and is also
not what I'm arguing for here right now. What the message you referred
to was about was the condescending attitude where we were told
On 09/06/2014 12:33 PM, Marko Tiikkaja wrote:
On 2014-09-06 6:31 PM, Jan Wieck wrote:
On 09/06/2014 12:17 PM, Marko Tiikkaja wrote:
OK, fine. But that's not what I suggested on the wiki page, and is also
not what I'm arguing for here right now. What the message you referred
to was about was
On Sat, Sep 6, 2014 at 12:38 PM, Jan Wieck-3 [via PostgreSQL]
ml-node+s1045698n5818047...@n5.nabble.com wrote:
On 09/06/2014 12:33 PM, Marko Tiikkaja wrote:
On 2014-09-06 6:31 PM, Jan Wieck wrote:
On 09/06/2014 12:17 PM, Marko Tiikkaja wrote:
OK, fine. But that's not what I suggested on
On 09/06/2014 12:47 PM, David G Johnston wrote:
If the language, and the system as a whole, was only used by
perfectionists that do not make errors - and with perfectly clean data -
this adherence to purity would be acceptable. But the real world is not
that clean and so enhancing the language
On Thu, Sep 4, 2014 at 6:40 PM, Florian Pflug f...@phlo.org wrote:
Cost of hidden IO cast is negative too. If we can change it, then we can
increase a sped.
But the whole power of PL/pgSQL comes from the fact that it allows you to
use the full set of postgres data types and operatores, and
On 09/05/2014 12:37 PM, Merlin Moncure wrote:
On Thu, Sep 4, 2014 at 6:40 PM, Florian Pflug f...@phlo.org wrote:
Cost of hidden IO cast is negative too. If we can change it, then we can
increase a sped.
But the whole power of PL/pgSQL comes from the fact that it allows you to
use the full set
On 2014-09-02 8:52 PM, Kevin Grittner wrote:
Marko Tiikkaja ma...@joh.to wrote:
Sounds like in this case you'd only use set-oriented programming
at the end of the transaction, no?
I guess -- more properly I would say in the final database
transaction for that financial transaction.
Yes, I
On 09/01/2014 04:04 AM, Joel Jacobson wrote:
+ Make UPDATE/INSERT/DELETE throw error if they didnt' modify exactly 1
row, as that's the most common use-case, and provide alternative syntax
to modify multiple or zero rows.
What? No. The whole point of SQL is that it's set-based and can modify
On 4 sep 2014, at 15:09, Shaun Thomas stho...@optionshouse.com wrote:
On 09/01/2014 04:04 AM, Joel Jacobson wrote:
+ Make UPDATE/INSERT/DELETE throw error if they didnt' modify exactly 1
row, as that's the most common use-case, and provide alternative syntax
to modify multiple or zero rows.
On 09/04/2014 02:48 AM, Robert Haas wrote:
To take another example, I've been complaining about the fact
that PostgreSQL 8.3+ requires far more typecasts in stored procedures
than any other database I'm aware of for years, probably since before
I joined EnterpriseDB.
+10
This still drives me
On 9/4/14 5:54 PM, Craig Ringer wrote:
On 09/04/2014 02:48 AM, Robert Haas wrote:
To take another example, I've been complaining about the fact
that PostgreSQL 8.3+ requires far more typecasts in stored procedures
than any other database I'm aware of for years, probably since before
I joined
On 09/04/2014 06:48 AM, Joshua D. Drake wrote:
On 09/03/2014 11:48 AM, Robert Haas wrote:
Anyway, to get back around to the topic of PL/SQL compatibility
specifically, if you care about that issue, pick one thing that exists
in PL/SQL but not in PL/pgsql and try to do something about it.
Hi Craig
2014-09-04 17:54 GMT+02:00 Craig Ringer cr...@2ndquadrant.com:
On 09/04/2014 02:48 AM, Robert Haas wrote:
To take another example, I've been complaining about the fact
that PostgreSQL 8.3+ requires far more typecasts in stored procedures
than any other database I'm aware of for
On 09/04/2014 09:02 AM, Craig Ringer wrote:
There are a few things I would like to see, like secure session
variables in PL/PgSQL. Mostly, though, I think talk of Oracle
compatibility seems to be something that comes up before the speaker
has really understood what that would mean, and the
2014-09-04 20:31 GMT+02:00 Josh Berkus j...@agliodbs.com:
On 09/04/2014 09:02 AM, Craig Ringer wrote:
There are a few things I would like to see, like secure session
variables in PL/PgSQL. Mostly, though, I think talk of Oracle
compatibility seems to be something that comes up before the
* Robert Haas (robertmh...@gmail.com) wrote:
Second, if you did manage to develop something which was significantly
more compatible with Oracle than PostgreSQL or PL/pgsql is today,
you'd probably find that the community wouldn't accept it.
Agreed. Moving PostgreSQL forward is what the
On Thu, Sep 4, 2014 at 2:31 PM, Josh Berkus j...@agliodbs.com wrote:
Sadly, what's prevented us from having packages already has been the
insistence of potential feature sponsors that they work *exactly* like
PL/SQL's packages, which is incompatible with Postgres namespacing.
Also, we'd want
On Sep4, 2014, at 20:50 , Pavel Stehule pavel.steh...@gmail.com wrote:
2014-09-04 20:31 GMT+02:00 Josh Berkus j...@agliodbs.com:
* The ability to compile functions/procedures for faster execution.
This point is more complex, because bottleneck is not in plpgsql - it is
terrible fast against
On 3 September 2014 01:08, Jan Wieck j...@wi3ck.info wrote:
On 09/02/2014 06:56 PM, Andrew Dunstan wrote:
People are free to do what they want, but to my mind that would be a
massive waste of resources, and probably imposing a substantial extra
maintenance burden on the core committers.
I
On Wed, Sep 3, 2014 at 7:54 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I am not against to improve a PL/pgSQL. And I repeat, what can be done and
can be done early:
a) ASSERT clause -- with some other modification to allow better static
analyze of DML statements, and enforces checks in
2014-09-03 9:14 GMT+02:00 Joel Jacobson j...@trustly.com:
On Wed, Sep 3, 2014 at 7:54 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I am not against to improve a PL/pgSQL. And I repeat, what can be done
and
can be done early:
a) ASSERT clause -- with some other modification to allow
On Wed, Sep 3, 2014 at 10:07 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
When you use name plpgsql2 you say, so plpgsql2 is successor plpgsql. It is
very hard to accept it. So any other name is not problem for me - like
plpgsql-safe-subset or something else
plpgsql2 *is* the successor of
On 09/02/2014 03:50 PM, Jan Wieck wrote:
PL/pgSQL's syntax was modelled to look like PL/SQL. Which is a Ada/COBOL
lookalike.
Instead of trying to mimic what it was or a T-SQL thing instead ...
maybe it is time to come up with a true PostgreSQL specific PL for a
change?
Just for the sake of
On 09/02/2014 04:01 PM, Álvaro Hernández Tortosa wrote:
It's not copying. It's easying a path for others to migrate and
come to Postgres.
I'm interested why you are more interested in MSSQL. My reasons for
being interested in Oracle are:
- It has more users (biggest and above all,
On Wed, Sep 3, 2014 at 3:17 PM, Joshua D. Drake j...@commandprompt.com wrote:
Well, I don't think PostgreSQL needs its own PL. I mean we already have
several (what other database has pl/javascript or pl/python?)
PostgreSQL already *have* it's own PL, it's called PL/pgSQL.
Besides, the idea of
On 09/03/2014 03:14 AM, Joel Jacobson wrote:
I'm in favour of Tom's idea. To merely make the plpgsql2 language a
way of explicitly saying you want
a specific exact combination of features/beaviour/settings which we
can implemented in plpgsql's existing codebase.
Since it was about 100 posts
On Tue, Sep 2, 2014 at 08:46:36PM -0400, Christopher Browne wrote:
3. Is there anything to be learned from Tutorial D? That is, Date Darwen's
would-be alternative to SQL of their Third Manifesto?
What would a set-oriented-language PL look like, such as APL? I guess
Perl has arrays, so it
On Wed, Sep 3, 2014 at 07:54:09AM +0200, Pavel Stehule wrote:
I am not against to improve a PL/pgSQL. And I repeat, what can be done and can
be done early:
a) ASSERT clause -- with some other modification to allow better static
analyze
of DML statements, and enforces checks in runtime.
On 9/3/14 5:05 PM, Bruce Momjian wrote:
On Wed, Sep 3, 2014 at 07:54:09AM +0200, Pavel Stehule wrote:
I am not against to improve a PL/pgSQL. And I repeat, what can be done and can
be done early:
a) ASSERT clause -- with some other modification to allow better static analyze
of DML
2014-09-03 17:05 GMT+02:00 Bruce Momjian br...@momjian.us:
On Wed, Sep 3, 2014 at 07:54:09AM +0200, Pavel Stehule wrote:
I am not against to improve a PL/pgSQL. And I repeat, what can be done
and can
be done early:
a) ASSERT clause -- with some other modification to allow better static
On 03/09/14 15:24, Joshua D. Drake wrote:
On 09/02/2014 04:01 PM, Álvaro Hernández Tortosa wrote:
It's not copying. It's easying a path for others to migrate and
come to Postgres.
I'm interested why you are more interested in MSSQL. My reasons for
being interested in Oracle are:
On Tue, Sep 2, 2014 at 5:47 PM, Álvaro Hernández Tortosa a...@nosys.es wrote:
Yeah, we differ there. I think having an Oracle compatibility layer in
PostgreSQL would be the-next-big-thing we could have. Oracle is has orders
of magnitude bigger user base than postgres has; and having the
This is more of an SQL request the pl/pgsql but is/has there been thought to
adding the ternary if/then opeator? Something like:
boolean_exp ? val_if_true : val_if_false
using ? by itself would be OK but not ideal - and the addition of the
doesn't seem hateful...
Sorry if this is deemed
2014-09-03 21:01 GMT+02:00 David G Johnston david.g.johns...@gmail.com:
This is more of an SQL request the pl/pgsql but is/has there been thought
to
adding the ternary if/then opeator? Something like:
boolean_exp ? val_if_true : val_if_false
using ? by itself would be OK but not ideal -
On 09/03/2014 11:48 AM, Robert Haas wrote:
Anyway, to get back around to the topic of PL/SQL compatibility
specifically, if you care about that issue, pick one thing that exists
in PL/SQL but not in PL/pgsql and try to do something about it. Maybe
it'll be something that EnterpiseDB has
On Tue, Sep 2, 2014 at 5:46 AM, Craig Ringer cr...@2ndquadrant.com 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
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
On Tue, Sep 2, 2014 at 8:26 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
2014-09-01 11:04 GMT+02:00 Joel Jacobson j...@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
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
2014-09-02 11:25 GMT+02:00 Álvaro Hernández Tortosa a...@nosys.es:
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
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
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
On 02/09/14 06:40, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com 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
2014-09-02 11:34 GMT+02:00 Marko Tiikkaja ma...@joh.to:
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 =
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
2014-09-02 11:40 GMT+02:00 Álvaro Hernández Tortosa a...@nosys.es:
On 02/09/14 06:40, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com 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,
On 02/09/14 11:31, Pavel Stehule wrote:
2014-09-02 11:25 GMT+02:00 Álvaro Hernández Tortosa a...@nosys.es
mailto:a...@nosys.es:
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
2014-09-02 11:44 GMT+02:00 Álvaro Hernández Tortosa a...@nosys.es:
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
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
2014-09-02 11:50 GMT+02:00 Álvaro Hernández Tortosa a...@nosys.es:
On 02/09/14 11:31, Pavel Stehule wrote:
2014-09-02 11:25 GMT+02:00 Álvaro Hernández Tortosa a...@nosys.es:
On 02/09/14 05:24, Craig Ringer wrote:
I couldn't disagree more.
If we were to implement anything, it'd be
On 02/09/14 11:56, Pavel Stehule wrote:
2014-09-02 11:50 GMT+02:00 Álvaro Hernández Tortosa a...@nosys.es
mailto:a...@nosys.es:
On 02/09/14 11:31, Pavel Stehule wrote:
2014-09-02 11:25 GMT+02:00 Álvaro Hernández Tortosa a...@nosys.es
mailto:a...@nosys.es:
On
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
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
On Tue, Sep 2, 2014 at 11:04 AM, Pavel Stehule pavel.steh...@gmail.com 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
On 09/02/2014 03:16 PM, Joel Jacobson wrote:
On Tue, Sep 2, 2014 at 11:04 AM, Pavel Stehule pavel.steh...@gmail.com 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
2014-09-02 14:16 GMT+02:00 Joel Jacobson j...@trustly.com:
On Tue, Sep 2, 2014 at 11:04 AM, Pavel Stehule pavel.steh...@gmail.com
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
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
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?
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 and...@dunslane.net wrote:
On 09/02/2014 05:44 AM, Álvaro
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
http://idallen.com/topposting.html
Unfortunately, I think the short answer is not very well. In theory we
2014-09-02 14:38 GMT+02:00 Andrew Dunstan and...@dunslane.net:
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
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
Joel Jacobson j...@trustly.com 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
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
On Tue, Sep 2, 2014 at 3:12 PM, Kevin Grittner kgri...@ymail.com wrote:
Joel Jacobson j...@trustly.com 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
On Tue, Sep 2, 2014 at 2:29 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On Tue, Sep 2, 2014 at 2:30 PM, Pavel Stehule pavel.steh...@gmail.com 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
On 09/02/2014 04:32 PM, Joel Jacobson wrote:
On Tue, Sep 2, 2014 at 2:29 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On Tue, Sep 2, 2014 at 3:41 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On 09/02/2014 04:52 PM, Joel Jacobson wrote:
On Tue, Sep 2, 2014 at 3:41 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On 9/2/14 3:52 PM, Joel Jacobson wrote:
On Tue, Sep 2, 2014 at 3:41 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On Tue, Sep 2, 2014 at 3:58 PM, Marko Tiikkaja ma...@joh.to 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
Marko Tiikkaja ma...@joh.to 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
On 2014-09-02 10:21:50 -0400, Tom Lane wrote:
Marko Tiikkaja ma...@joh.to 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
Joel Jacobson j...@trustly.com wrote:
On Tue, Sep 2, 2014 at 3:12 PM, Kevin Grittner kgri...@ymail.com wrote:
Joel Jacobson j...@trustly.com 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
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
On 9/2/14 4:26 PM, Kevin Grittner wrote:
Joel Jacobson j...@trustly.com 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.
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 adds Oracle
Marko Tiikkaja ma...@joh.to wrote:
On 9/2/14 4:26 PM, Kevin Grittner wrote:
Joel Jacobson j...@trustly.com 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.
On Sep 1, 2014, at 10:24 PM, Craig Ringer cr...@2ndquadrant.com 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
On 9/2/14 5:08 PM, Kevin Grittner wrote:
Marko Tiikkaja ma...@joh.to wrote:
On 9/2/14 4:26 PM, Kevin Grittner wrote:
Joel Jacobson j...@trustly.com 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
On Tue, Sep 2, 2014 at 5:08 PM, Kevin Grittner kgri...@ymail.com wrote:
Marko Tiikkaja ma...@joh.to 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
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 'TRUNCATE
On 09/02/2014 06:44 PM, Joel Jacobson wrote:
On Tue, Sep 2, 2014 at 5:08 PM, Kevin Grittner kgri...@ymail.com wrote:
Marko Tiikkaja ma...@joh.to 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
Joel Jacobson j...@trustly.com 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
On Tue, Sep 2, 2014 at 6:03 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I think that would actually be a good way to enforce the rule that an UPDATE
only updates a single row. Just put a ASSERT ROW_COUNT=1; after the
update.
So instead of one line of code, I would need to write two
On 02/09/14 17:03, Hannu Krosing wrote:
On 09/02/2014 11:52 AM, Álvaro Hernández Tortosa wrote:
On 02/09/14 11:44, Pavel Stehule wrote:
For 9.4, we have the media already saying Postgres has
NoSQL capabilities (which is only partially true). For x.y we
could have the
1 - 100 of 225 matches
Mail list logo
