On Tue, Sep 2, 2014 at 6:09 PM, Kevin Grittner kgri...@ymail.com wrote:
Joel Jacobson j...@trustly.com wrote:
Sorry for being unclear, I didn't mean to suggest the main concern is
updating *all* rows.
The main concern is when you have a rather complex UPDATE WHERE clause,
aiming to update
On 09/02/2014 12:12 PM, Joel Jacobson wrote:
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
On Tue, Sep 2, 2014 at 6:11 PM, Álvaro Hernández Tortosa a...@nosys.es wrote:
We are definitely worse. This is the problem, we only look to our own
belly bottom (if this expression exists in English). All NoSQL scale
*easily*, *transparently* beyond one node. Postgres doesn't. I'm not
2014-09-02 18:03 GMT+02:00 Heikki Linnakangas hlinnakan...@vmware.com:
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
On 02/09/14 18:20, Joel Jacobson wrote:
On Tue, Sep 2, 2014 at 6:09 PM, Kevin Grittner kgri...@ymail.com wrote:
Joel Jacobson j...@trustly.com wrote:
Sorry for being unclear, I didn't mean to suggest the main concern is
updating *all* rows.
The main concern is when you have a rather complex
On 09/02/2014 07:12 PM, Joel Jacobson wrote:
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
On 09/02/2014 06:27 PM, Joel Jacobson wrote:
On Tue, Sep 2, 2014 at 6:11 PM, Álvaro Hernández Tortosa a...@nosys.es
wrote:
We are definitely worse. This is the problem, we only look to our own
belly bottom (if this expression exists in English). All NoSQL scale
*easily*, *transparently*
On 02/09/14 18:33, Hannu Krosing wrote:
On 09/02/2014 06:27 PM, Joel Jacobson wrote:
On Tue, Sep 2, 2014 at 6:11 PM, Álvaro Hernández Tortosa a...@nosys.es wrote:
We are definitely worse. This is the problem, we only look to our own
belly bottom (if this expression exists in English).
On Tue, Sep 2, 2014 at 04:24:11PM +0200, Andres Freund wrote:
On 2014-09-02 10:21:50 -0400, Tom Lane wrote:
Marko Tiikkaja 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
On Tue, Sep 2, 2014 at 12:40:14AM -0400, 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
On 9/2/14 6:03 PM, Heikki Linnakangas wrote:
Marko posted a patch to add assertions to PL/pgSQL last year, see
http://www.postgresql.org/message-id/5234af3f.4000...@joh.to. It was a
long thread, but in the end I think everyone was more or less OK with
the syntax ASSERT condition;. I also think
On Tue, Sep 2, 2014 at 6:31 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I don't think most applications are like that. See Kevin's comments about
doing things in a set-oriented way instead of row-by-row. I know I've
changed several procedures from the row-oriented style, looping over
On Tue, Sep 2, 2014 at 6:45 PM, Bruce Momjian br...@momjian.us wrote:
SINGLETON UPDATE ...?
Does it come with built-in spell check? :-) It's a bit long to write.
I like STRICT, that maps good to what we already have with SELECT ...
INTO STRICT.
--
Sent via pgsql-hackers mailing list
On Tue, Sep 2, 2014 at 06:57:42PM +0200, Joel Jacobson wrote:
On Tue, Sep 2, 2014 at 6:45 PM, Bruce Momjian br...@momjian.us wrote:
SINGLETON UPDATE ...?
Does it come with built-in spell check? :-) It's a bit long to write.
I like STRICT, that maps good to what we already have with SELECT
On Tue, Sep 2, 2014 at 7:01 PM, Bruce Momjian br...@momjian.us wrote:
On Tue, Sep 2, 2014 at 06:57:42PM +0200, Joel Jacobson wrote:
On Tue, Sep 2, 2014 at 6:45 PM, Bruce Momjian br...@momjian.us wrote:
SINGLETON UPDATE ...?
Does it come with built-in spell check? :-) It's a bit long to
On 9/2/14 6:31 PM, Heikki Linnakangas wrote:
On 09/02/2014 07:12 PM, Joel Jacobson wrote:
For me, updating a row, is like setting a variable in a normal language.
No normal language would require two rows to set a variable.
It would be like having to do:
my $var = 10;
die unless $var
Marko Tiikkaja ma...@joh.to wrote:
Well, just off the top of my head a normal function invocation could be:
one worker working on a single order started by a single end user to
transfer money from one account to another. And we have *a lot* of code
like this where there isn't a way to write
On 09/02/2014 07:51 PM, Marko Tiikkaja wrote:
On 9/2/14 6:03 PM, Heikki Linnakangas wrote:
Marko posted a patch to add assertions to PL/pgSQL last year, see
http://www.postgresql.org/message-id/5234af3f.4000...@joh.to. It was a
long thread, but in the end I think everyone was more or less OK
2014-09-02 15:58 GMT+02:00 Marko Tiikkaja ma...@joh.to:
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
On 2014-09-02 19:33, Kevin Grittner wrote:
Marko Tiikkaja ma...@joh.to wrote:
Well, just off the top of my head a normal function invocation could be:
one worker working on a single order started by a single end user to
transfer money from one account to another. And we have *a lot* of code
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. And no, that never
made me wish that plpgsql functions
On Tue, Sep 2, 2014 at 07:06:02PM +0200, Joel Jacobson wrote:
On Tue, Sep 2, 2014 at 7:01 PM, Bruce Momjian br...@momjian.us wrote:
On Tue, Sep 2, 2014 at 06:57:42PM +0200, Joel Jacobson wrote:
On Tue, Sep 2, 2014 at 6:45 PM, Bruce Momjian br...@momjian.us wrote:
SINGLETON UPDATE ...?
On 2014-09-02 19:06:02 +0200, Joel Jacobson wrote:
But what do you think about,
STRICT UPDATE ...?
I quite dislike it. An UPDATE isn't less 'strict' (whatever that means)
if updates more than one row. There's some sense in the way it's used
for INTO because it's referring to the INTO. And it's
On Mon, Sep 1, 2014 at 4:04 AM, Joel Jacobson j...@trustly.com wrote:
Hi,
For those of you who use PL/pgSQL every day, I'm quite certain you all feel
there are a number of things you would like to change in the language, but
realize it cannot be achieved without possibly breaking
On 09/02/2014 09:48 AM, Bruce Momjian wrote:
As a case in point, EDB have spent quite a few man-years on their Oracle
compatibility layer; and it's still not a terribly exact match, according
to my colleagues who have looked at it. So that is a tarbaby I don't
personally care to touch ...
Without having read the entire thread ...
On 09/01/2014 05:04 AM, Joel Jacobson wrote:
From the top of my head, these are Things I personally would want to
see in plpgsql2:
+ Make UPDATE/INSERT/DELETE throw error if they didnt' modify exactly 1
row, as that's the most common use-case, and
On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake j...@commandprompt.com
wrote:
On 09/02/2014 09:48 AM, Bruce Momjian wrote:
As a case in point, EDB have spent quite a few man-years on their Oracle
compatibility layer; and it's still not a terribly exact match, according
to my colleagues who
On Tue, Sep 2, 2014 at 10:16 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-02 19:06:02 +0200, Joel Jacobson wrote:
But what do you think about,
STRICT UPDATE ...?
I quite dislike it. An UPDATE isn't less 'strict' (whatever that means)
if updates more than one row. There's some
On 09/01/2014 09:06 PM, Andrew Dunstan wrote:
On 09/01/2014 08:09 PM, Neil Tiffin wrote:
The docs also tell you how to avoid having to do this, using dollar quoting.
That should be enough alone to suggest postgreSQL start working on a modern, in
core, fast, fully supported language. Of
On Tue, Sep 2, 2014 at 10:27 PM, Merlin Moncure mmonc...@gmail.com wrote:
What is the reasoning for breaking compatibiilty? Why not improve the
language that's there?
Because many suggested improvement are not possible without
breaking compatibility, at least in theory. See previous posts in
On 09/02/2014 12:20 PM, Joel Jacobson wrote:
On Tue, Sep 2, 2014 at 6:09 PM, Kevin Grittner kgri...@ymail.com wrote:
Joel Jacobson j...@trustly.com wrote:
Sorry for being unclear, I didn't mean to suggest the main concern is
updating *all* rows.
The main concern is when you have a rather
On 09/01/2014 10:41 AM, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer cr...@2ndquadrant.com wrote:
Well, the idiom:
EXECUTE format(SELECT %I FROM %I WHERE $1, col, tbl) USING val;
is not lovely. It works, but it's clumsy.
This is exactly why we need a new language.
All
On 02/09/14 23:11, David Johnston wrote:
On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake j...@commandprompt.com
mailto:j...@commandprompt.comwrote:
On 09/02/2014 09:48 AM, Bruce Momjian wrote:
As a case in point, EDB have spent quite a few man-years
on their
On 09/02/2014 02:11 PM, David Johnston wrote:
On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake j...@commandprompt.com
mailto:j...@commandprompt.comwrote:
On 09/02/2014 09:48 AM, Bruce Momjian wrote:
As a case in point, EDB have spent quite a few man-years on
their
On 09/02/2014 09:32 AM, Joel Jacobson wrote:
I think it's much better to make it the default behaviour in plpgsql2
than to add a new syntax to plpgsql,
because then we don't have to argue what to call the keyword or where to put it.
This should in NO CASE be any new syntax to plpgsql or
On 02/09/14 23:34, Joshua D. Drake wrote:
On 09/02/2014 02:11 PM, David Johnston wrote:
On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake j...@commandprompt.com
mailto:j...@commandprompt.comwrote:
On 09/02/2014 09:48 AM, Bruce Momjian wrote:
As a case in point, EDB have spent
On 09/02/2014 04:16 PM, Andres Freund wrote:
On 2014-09-02 19:06:02 +0200, Joel Jacobson wrote:
But what do you think about,
STRICT UPDATE ...?
I quite dislike it. An UPDATE isn't less 'strict' (whatever that means)
if updates more than one row. There's some sense in the way it's used
for
On 09/01/2014 02:04 AM, Joel Jacobson wrote:
Please share your wish list of things you would want in plpgsql2 which
are not possible to implement in plpgsql because they could possibly
break compatibility.
Well, if I were designing a new procedural SQL extension language, I
wouldn't base it on
On 09/02/2014 03:19 PM, Josh Berkus wrote:
Well, if I were designing a new procedural SQL extension language, I
wouldn't base it on the bastard child of ADA and SQL89. I would come up
Ada, that is. One is a programming language, the other is the bane of
architects.
--
Josh Berkus
PostgreSQL
On 09/02/2014 02:47 PM, Álvaro Hernández Tortosa wrote:
Yeah, we differ there. I think having an Oracle compatibility layer
in PostgreSQL would be the-next-big-thing we could have. Oracle is has
orders of magnitude bigger user base than postgres has; and having the
ability to attract them
On 09/02/2014 03:19 PM, Josh Berkus wrote:
On 09/01/2014 02:04 AM, Joel Jacobson wrote:
Please share your wish list of things you would want in plpgsql2 which
are not possible to implement in plpgsql because they could possibly
break compatibility.
Well, if I were designing a new procedural
On 09/02/2014 06:41 PM, Joshua D. Drake wrote:
On 09/02/2014 02:47 PM, Álvaro Hernández Tortosa wrote:
Yeah, we differ there. I think having an Oracle compatibility layer
in PostgreSQL would be the-next-big-thing we could have. Oracle is has
orders of magnitude bigger user base than
On 09/02/2014 06:50 PM, Jan Wieck wrote:
On 09/02/2014 06:41 PM, Joshua D. Drake wrote:
On 09/02/2014 02:47 PM, Álvaro Hernández Tortosa wrote:
Yeah, we differ there. I think having an Oracle compatibility
layer
in PostgreSQL would be the-next-big-thing we could have. Oracle is has
On 03/09/14 00:41, Joshua D. Drake wrote:
On 09/02/2014 02:47 PM, Álvaro Hernández Tortosa wrote:
Yeah, we differ there. I think having an Oracle compatibility layer
in PostgreSQL would be the-next-big-thing we could have. Oracle is has
orders of magnitude bigger user base than postgres
On 09/02/2014 06:56 PM, Andrew Dunstan wrote:
People are free to do what they want, but to my mind that would be a
massive waste of resources, and probably imposing a substantial extra
maintenance burden on the core committers.
I hear you and agree to some degree.
But at the same time I
On Tue, Sep 2, 2014 at 7:08 PM, 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.
On Wed, Sep 3, 2014 at 12:19 AM, Josh Berkus j...@agliodbs.com wrote:
On 09/01/2014 02:04 AM, Joel Jacobson wrote:
Please share your wish list of things you would want in plpgsql2 which
are not possible to implement in plpgsql because they could possibly
break compatibility.
Well, if I were
On Wed, Sep 3, 2014 at 2:46 AM, Christopher Browne cbbro...@gmail.com wrote:
The notion of hacking features onto plpgsql2 that mostly seem like SQL
enhancements is a waste of time.
New versions of languages who change too much in a new version are
doomed to fail. There are many such examples in
2014-09-03 7:07 GMT+02:00 Joel Jacobson j...@trustly.com:
On Wed, Sep 3, 2014 at 12:19 AM, Josh Berkus j...@agliodbs.com wrote:
On 09/01/2014 02:04 AM, Joel Jacobson wrote:
Please share your wish list of things you would want in plpgsql2 which
are not possible to implement in plpgsql
On Wed, Sep 3, 2014 at 7:17 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
yes, but there is minimal agreement of direction of movement. I am not alone
who are thinking so your proposal is not good for general usage.
Minimal agreement? That's not true. The other group of users have been
2014-09-03 7:23 GMT+02:00 Joel Jacobson j...@trustly.com:
On Wed, Sep 3, 2014 at 7:17 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
yes, but there is minimal agreement of direction of movement. I am not
alone
who are thinking so your proposal is not good for general usage.
Minimal
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.
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
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
On Mon, Sep 1, 2014 at 11:24 AM, Andres Freund and...@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
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
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
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
On Mon, Sep 1, 2014 at 12:32 PM, Hannu Krosing ha...@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
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
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
On Mon, Sep 1, 2014 at 12:55 PM, Andres Freund and...@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
Hi
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,
2014-09-01 13:30 GMT+02:00 Joel Jacobson j...@trustly.com:
On Mon, Sep 1, 2014 at 12:55 PM, Andres Freund and...@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
On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule pavel.steh...@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
2014-09-01 14:27 GMT+02:00 Joel Jacobson j...@trustly.com:
On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule pavel.steh...@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
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.
On 9/1/14 2:53 PM, Pavel Stehule wrote:
2014-09-01 14:27 GMT+02:00 Joel Jacobson j...@trustly.com:
On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule pavel.steh...@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
On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule pavel.steh...@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,
On 2014-09-01 15:19:41 +0200, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule pavel.steh...@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
On 09/01/2014 05:04 PM, Joel Jacobson wrote:
Just like with plpgsql, once released, plpgsql2 cannot break
compatibility with future versions, so we only have one chance to
carefully think though what we would like to change in the language.
You're not proposing to copy plpgsql's runtime
On 09/01/2014 05:04 PM, Joel Jacobson wrote:
From the top of my head, these are Things I personally would want to see
in plpgsql2:
Oh, also, I'd *love* to improve how non-plannable statements with
PL/PgSQL variable subsitutions behave.
*I* understand why the following is wrong:
DO
$$
DECLARE
2014-09-01 15:12 GMT+02:00 Marko Tiikkaja ma...@joh.to:
On 9/1/14 2:53 PM, Pavel Stehule wrote:
2014-09-01 14:27 GMT+02:00 Joel Jacobson j...@trustly.com:
On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I agree with Andres - it is not a good for plpgsql and
2014-09-01 15:52 GMT+02:00 Craig Ringer cr...@2ndquadrant.com:
On 09/01/2014 05:04 PM, Joel Jacobson wrote:
From the top of my head, these are Things I personally would want to see
in plpgsql2:
Oh, also, I'd *love* to improve how non-plannable statements with
PL/PgSQL variable
On 09/01/2014 09:58 PM, Pavel Stehule wrote:
It is in ToDo - allow parametrization for COMMANDs.
But this is one point, when I am not sure if we would it. Now -
situation is very simply. Variables should not be used as table or
column name. With your proposal, the situation will by much
2014-09-01 16:01 GMT+02:00 Craig Ringer cr...@2ndquadrant.com:
On 09/01/2014 09:58 PM, Pavel Stehule wrote:
It is in ToDo - allow parametrization for COMMANDs.
But this is one point, when I am not sure if we would it. Now -
situation is very simply. Variables should not be used as
On 2014-09-01 22:01:33 +0800, Craig Ringer wrote:
On 09/01/2014 09:58 PM, Pavel Stehule wrote:
It is in ToDo - allow parametrization for COMMANDs.
But this is one point, when I am not sure if we would it. Now -
situation is very simply. Variables should not be used as table or
On 09/01/2014 10:11 PM, Pavel Stehule wrote:
It can be solution, but I dislike it .. It increase a language
complexity .. vars with or without prefix .. and more, hidden dynamic SQL
Nothing what I like - I have a mental barrier to this concept.
Yeah - the question is whether it's better
On 09/01/2014 10:17 PM, Andres Freund wrote:
Imo this is still something that's more dynamic SQL (i.e. EXECUTE's
remit) than something that shouldn't be doable implicitly. So perhaps
the solution is to extend EXECUTE to allow specifying tablenames as
variables more conveniently?
With
2014-09-01 16:18 GMT+02:00 Craig Ringer cr...@2ndquadrant.com:
On 09/01/2014 10:11 PM, Pavel Stehule wrote:
It can be solution, but I dislike it .. It increase a language
complexity .. vars with or without prefix .. and more, hidden dynamic
SQL
Nothing what I like - I have a mental
On 2014-09-01 22:20:37 +0800, Craig Ringer wrote:
On 09/01/2014 10:17 PM, Andres Freund wrote:
Imo this is still something that's more dynamic SQL (i.e. EXECUTE's
remit) than something that shouldn't be doable implicitly. So perhaps
the solution is to extend EXECUTE to allow specifying
On 09/01/2014 10:24 PM, Andres Freund wrote:
I know of format(), but it doesn't allow you to pass parameters as
actual query variables unfortunately.
I'm wondering if there's a way to marry USING and format()...
Well, the idiom:
EXECUTE format(SELECT %I FROM %I WHERE $1, col, tbl) USING
On Mon, Sep 1, 2014 at 3:25 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-01 15:19:41 +0200, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
It bad signal to have two languages plpgsql and plpgsql2. Who will believe
to us so we
+1
I use underscore for *all* variables and input parameters in all
functions. Making that a requirement in plpgsql2 wouldn't break any of
my code.
On Mon, Sep 1, 2014 at 3:52 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 09/01/2014 05:04 PM, Joel Jacobson wrote:
From the top of my head,
2014-09-01 16:26 GMT+02:00 Craig Ringer cr...@2ndquadrant.com:
On 09/01/2014 10:24 PM, Andres Freund wrote:
I know of format(), but it doesn't allow you to pass parameters as
actual query variables unfortunately.
I'm wondering if there's a way to marry USING and format()...
Well, the
On 09/01/2014 03:45 PM, Craig Ringer wrote:
On 09/01/2014 05:04 PM, Joel Jacobson wrote:
Just like with plpgsql, once released, plpgsql2 cannot break
compatibility with future versions, so we only have one chance to
carefully think though what we would like to change in the language.
You're
On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer cr...@2ndquadrant.com wrote:
Well, the idiom:
EXECUTE format(SELECT %I FROM %I WHERE $1, col, tbl) USING val;
is not lovely. It works, but it's clumsy.
This is exactly why we need a new language.
All the clumsy stuff we cannot fix in plpgsql,
On 2014-09-01 16:29:18 +0200, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 3:25 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-01 15:19:41 +0200, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
It bad signal to have two
On 09/01/2014 05:41 PM, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer cr...@2ndquadrant.com wrote:
Well, the idiom:
EXECUTE format(SELECT %I FROM %I WHERE $1, col, tbl) USING val;
is not lovely. It works, but it's clumsy.
This is exactly why we need a new language.
2014-09-01 16:39 GMT+02:00 Hannu Krosing ha...@2ndquadrant.com:
On 09/01/2014 03:45 PM, Craig Ringer wrote:
On 09/01/2014 05:04 PM, Joel Jacobson wrote:
Just like with plpgsql, once released, plpgsql2 cannot break
compatibility with future versions, so we only have one chance to
2014-09-01 16:41 GMT+02:00 Joel Jacobson j...@trustly.com:
On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer cr...@2ndquadrant.com
wrote:
Well, the idiom:
EXECUTE format(SELECT %I FROM %I WHERE $1, col, tbl) USING val;
is not lovely. It works, but it's clumsy.
This is exactly why we
On Mon, Sep 1, 2014 at 4:41 PM, Andres Freund and...@2ndquadrant.com wrote:
I'm just saying it's much less probable you can add new features to
plpgsql than to plpgsql2, as you have to take into account the risk of
breaking compatibility.
That's just a difference of one release. The release
On 09/01/2014 10:41 PM, Joel Jacobson wrote:
This is exactly why we need a new language.
All the clumsy stuff we cannot fix in plpgsql, can easily be fixed in
plpgsql2, with the most beautiful syntax we can come up with.
I guess it's a question if we want to support things like this. If we
On Mon, Sep 1, 2014 at 5:16 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 09/01/2014 10:41 PM, Joel Jacobson wrote:
This is exactly why we need a new language.
All the clumsy stuff we cannot fix in plpgsql, can easily be fixed in
plpgsql2, with the most beautiful syntax we can come up with.
Joel Jacobson-2 wrote
On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer lt;
craig@
gt; wrote:
Well, the idiom:
EXECUTE format(SELECT %I FROM %I WHERE $1, col, tbl) USING val;
is not lovely. It works, but it's clumsy.
This is exactly why we need a new language.
All the clumsy stuff we
Andres Freund and...@2ndquadrant.com writes:
On 2014-09-01 15:19:41 +0200, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
It bad signal to have two languages plpgsql and plpgsql2. Who will believe
to us so we will continue development of
On Mon, Sep 1, 2014 at 5:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What is actually being proposed, AFAICS, is a one-shot fix for a bunch
of unfortunate choices. That might be worth doing, but let's not fool
ourselves about whether it's one-shot or not.
I'm glad to hear you think it *might*
On 01/09/14 14:27, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule pavel.steh...@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
2014-09-01 20:23 GMT+02:00 Joel Jacobson j...@trustly.com:
On Mon, Sep 1, 2014 at 5:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What is actually being proposed, AFAICS, is a one-shot fix for a bunch
of unfortunate choices. That might be worth doing, but let's not fool
ourselves about
Joel Jacobson j...@trustly.com writes:
I see two possible approaches of a plpgsql2 project, both aiming to
require minimal/no changes of most existing best-practice plpgsql
code:
a) fork plpgsql code base and implement changes with as few lines of
code as possible, making it easier to
101 - 200 of 224 matches
Mail list logo
