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 Thu, Aug 28, 2014 at 8:05 PM, Peter Geoghegan p...@heroku.com wrote:
I realized that I missed a few cases here. For one thing, the posted
patch fails to arrange for the UPDATE post-parse-analysis tree
representation to go through the rewriter stage (on the theory that
user-defined rules
On Wed, Aug 27, 2014 at 11:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 26, 2014 at 8:14 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Aug 19, 2014 at 6:37 PM, Rahila Syed rahilasye...@gmail.com wrote:
Hello,
Thank you for comments.
Could you tell me where the patch for
On Thu, Aug 28, 2014 at 12:46 AM, Arthur Silva arthur...@gmail.com wrote:
Em 26/08/2014 09:16, Fujii Masao masao.fu...@gmail.com escreveu:
On Tue, Aug 19, 2014 at 6:37 PM, Rahila Syed rahilasye...@gmail.com
wrote:
Hello,
Thank you for comments.
Could you tell me where the patch for
On Mon, Sep 1, 2014 at 4:44 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Sep 1, 2014 at 3:23 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
I think there is one downside as well for this proposal that
apart from data loss, it can lead to uncommitted data occupying
space in database
On Tue, Sep 2, 2014 at 1:06 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 09/02/2014 11:10 AM, Sawada Masahiko wrote:
The currently patch dose not hack catalog, just create new index
concurrently and
swap them.
So, It is supporting only UNIQUE index, I think.
UNIQUE indexes, but not a
On Mon, Sep 1, 2014 at 10:54 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Mon, Sep 1, 2014 at 3:57 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Aug 30, 2014 at 12:27 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Wed, Aug 27, 2014 at 7:16 PM, Fujii Masao masao.fu...@gmail.com
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
Hi, I also tried this. This looks nice but seems a bit difficult
to find a rasonable behavior.
I have worked on that patch a little more. So now I have functional patch
(although still WIP) attached. The feature works as following:
- Added a boolean parameter only_temp_files to
We use benchmarksql to start tpcc test in postgresql 9.3.3.
Before test we set benchmarksql client number about 800. And we increase the
hash partitions from 16 to 1024 , in order to reduce the hash partition locks
competition.
We expect that after increase the number of partitions, reduces
Hello Marko,
I've changed the loop slightly. Do you find this more readable than the way
the loop was previously written?
It is 50% better:-)
It is no big deal, but I still fail to find the remaining continue as
usefull in this case. If you remove the continue line and invert the
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/01 20:15), Etsuro Fujita wrote:
While working on [1], I've found that postgres_fdw behaves oddly:
postgres=# create foreign table ft (a int) server loopback options
(table_name 't');
CREATE FOREIGN TABLE
postgres=# select tableoid, * from ft;
tableoid | a
--+---
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 2014-09-02 12:34:12 +0900, Sawada Masahiko wrote:
On Tue, Sep 2, 2014 at 11:12 AM, Andres Freund and...@2ndquadrant.com wrote:
I've now used up a perfectly good glass of wine for this, so this is it
for today ;)
Thank you for updating the patch!
I tested it.
These fix looks good to
On Tue, Sep 2, 2014 at 2:09 PM, Xiaoyulei xiaoyu...@huawei.com wrote:
We use benchmarksql to start tpcc test in postgresql 9.3.3.
Before test we set benchmarksql client number about 800. And we increase
the hash partitions from 16 to 1024 , in order to reduce the hash partition
locks
I already modified MAX_SIMUL_LWLOCKS to make sure it is enough.
Total RAM is 130G, and I set shared_buffers 16G, CPU and IO is not full. 50%
CPUs are idle. So I think maybe pg is blocked by some place in itself.
发件人: Amit Kapila [mailto:amit.kapil...@gmail.com]
发送时间: 2014年9月2日 19:31
收件人:
Hi Pavel,
it needs a redesign of original implementation, we should to change API to
use default values with named parameters
but it doesn't help too much (although it can be readable little bit more)
instead row_to_json(x, false, true)
be
row_ro_json(x, ignore_null := true)
it is not
Hello,
It'd be interesting to check avg cpu usage as well
I have collected average CPU utilization numbers by collecting sar output
at interval of 10 seconds for following benchmark:
Server specifications:
Processors:Intel® Xeon ® Processor E5-2650 (2 GHz, 8C/16T, 20 MB) * 2 nos
RAM: 32GB
Disk
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 08/19/2014 05:38 PM, Andres Freund wrote:
On 2014-08-19 10:33:29 -0400, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Barring objections or better ideas, I'm leaning towards
XLogReadBufferForRedo.
WFM
for me too. Although we could imo strip the 'XLog' in the beginning if
we want to
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
On 09/02/2014 11:52 AM, Fabien COELHO wrote:
I've changed the loop slightly. Do you find this more readable than the way
the loop was previously written?
It is 50% better:-)
It is no big deal, but I still fail to find the remaining continue as
usefull in this case. If you remove the
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 9:11 AM, Rahila Syed rahilasye...@gmail.com wrote:
Hello,
It'd be interesting to check avg cpu usage as well
I have collected average CPU utilization numbers by collecting sar output
at interval of 10 seconds for following benchmark:
Server specifications:
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
Hi,
I'm sorry for slow reaction.
I don't care whether rounding up or down it, although this title has
'rounding up'.
(I just only come up with it. I'm sorry for my imprudence)
I'm thinking about a method which users get quick awareness it.
Now, it's okay not to change current behavior except
On Tue, Sep 02, 2014 at 10:30:11AM -0300, Arthur Silva wrote:
On Tue, Sep 2, 2014 at 9:11 AM, Rahila Syed rahilasye...@gmail.com wrote:
Hello,
It'd be interesting to check avg cpu usage as well
I have collected average CPU utilization numbers by collecting sar output
at interval of
On 2014-09-02 08:37:42 -0500, k...@rice.edu wrote:
I agree completely. For day-to-day use we should use LZ4-default. For
read-only
tables, it might be nice to archive them with LZ4-HC for the higher
compression
would increase read speed and reduce storage space needs. I believe that
Etsuro Fujita wrote:
Please find attached the updated version of the patch.
I gave it a spin and could not find any undesirable behaviour, and the
output of EXPLAIN ANALYZE looks like I'd expect.
I noticed that you use the list length of fdw_private to check if
the UPDATE or DELETE is pushed
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 Sun, Aug 31, 2014 at 10:45:29PM +0200, Martijn van Oosterhout wrote:
There is one situation where you need to be more flexible, and that is
if you ever want to support online repartitioning. To do that you have
to distinguish between I want to insert tuple X, which partition
should it go
Noah Misch n...@leadboat.com writes:
I'm with you that far. Given a patch that does not change \s /tmp/foo and
that makes \s equivalent to \s /tmp/foo + \! cat /tmp/foo /dev/tty,
back-patch by all means. No patch posted on this thread is so surgical, hence
my objection. In particular, your
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
Fujii Masao wrote:
On Mon, Sep 1, 2014 at 10:54 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Mon, Sep 1, 2014 at 3:57 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Aug 30, 2014 at 12:27 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Wed, Aug 27, 2014 at 7:16 PM, Fujii
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 09/02/2014 04:12 PM, Alvaro Herrera wrote:
Fujii Masao wrote:
On Mon, Sep 1, 2014 at 10:54 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Mon, Sep 1, 2014 at 3:57 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Aug 30, 2014 at 12:27 PM, Amit Kapila amit.kapil...@gmail.com
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
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 Tue, Sep 2, 2014 at 5:20 PM, Xiaoyulei xiaoyu...@huawei.com wrote:
I already modified MAX_SIMUL_LWLOCKS to make sure it is enough.
Okay.
Total RAM is 130G, and I set shared_buffers 16G, CPU and IO is not full.
50% CPUs are idle.
As far as I understand, benchmarkSQL measures an OLTP
On Mon, Sep 1, 2014 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
OTOH, I agree with Kevin that the things we're talking about are
lightweight relations not variables.
My worry is that PL/pgSQL and Postgres's SQL dialect is turning into a
Frankenstein monster with many ways to do the same
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
On Tue, Aug 26, 2014 at 1:02 AM, Fabien COELHO coe...@cri.ensmp.fr wrote:
Hello again,
I have not found any mean to force bgwriter to send writes when it can.
(Well, I have: create a process which sends CHECKPOINT every 0.2
seconds... it works more or less, but this is not my point:-)
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
There is scan_whole_pool_milliseconds, which currently forces bgwriter to
circle the buffer pool at least once every 2 minutes. It is currently
fixed, but it should be trivial to turn it into an experimental guc that
you could use to test your hypothesis.
I recompiled with the variable
Re: Vik Fearing 2014-09-02 5405d2d9.9050...@dalibo.com
Uhm, are we agreed on the decision on not to backpatch this? I would
think this should have been part of the initial ALTER SYSTEM SET patch
and thus should be backpatched to 9.4.
I think it belongs in 9.4 as well, especially if we're
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 8:14 AM, Fabien COELHO coe...@cri.ensmp.fr wrote:
There is scan_whole_pool_milliseconds, which currently forces bgwriter to
circle the buffer pool at least once every 2 minutes. It is currently
fixed, but it should be trivial to turn it into an experimental guc that
On Sun, Aug 31, 2014 at 6:10 AM, Peter Eisentraut pete...@gmx.net wrote:
On 8/30/14 2:26 AM, Jeff Janes wrote:
But there cases were people use COPY in a loop with a small amount of
data in each statement.
What would be the reason for doing that?
As far as I can tell, DRY. They need code
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
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
1 - 100 of 170 matches
Mail list logo
