Re: [HACKERS] PL/pgSQL 2

On 3 September 2014 01:08, Jan Wieck 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 hea

Re: [HACKERS] PL/pgSQL 2

2014-09-03 7:23 GMT+02:00 Joel Jacobson : > On Wed, Sep 3, 2014 at 7:17 AM, Pavel Stehule > 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 ot

Re: [HACKERS] Patch for psql History Display on MacOSX

On Tue, Sep 02, 2014 at 09:49:56AM -0400, Tom Lane wrote: > Noah Misch 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 threa

Re: [HACKERS] ALTER TABLESPACE MOVE command tag tweak

Fujii, * Fujii Masao (masao.fu...@gmail.com) wrote: > You seem to have forgotten to update tab-complete.c. Good point, absolutely correct. I have a bad tendency to do that. > Attached patch updates that. Many thanks, will review and apply soon. Thanks again! Stephen

Re: [HACKERS] pg_upgrade and epoch

On Tue, Sep 2, 2014 at 7:59 PM, Bruce Momjian wrote: > On Wed, Apr 23, 2014 at 12:41:41PM -0700, Sergey Konoplev wrote: >> On Wed, Apr 23, 2014 at 5:26 AM, Bruce Momjian wrote: >> > Sergey, are you seeing a problem only because you are >> > interacting with other systems that didn't reset their e

Re: [HACKERS] ALTER TABLESPACE MOVE command tag tweak

On Fri, Aug 22, 2014 at 8:14 AM, Stephen Frost wrote: > Alvaro, > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: >> ALTER TABLE ALL IN TABLESPACE xyz >> which AFAICS should work since ALL is already a reserved keyword. > > Pushed to master and REL9_4_STABLE. You seem to have forgotten to up

Re: [HACKERS] PL/pgSQL 2

On Wed, Sep 3, 2014 at 7:17 AM, Pavel Stehule 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 discussing a completely new

Re: [HACKERS] PL/pgSQL 2

On Wed, Sep 3, 2014 at 2:46 AM, Christopher Browne 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 history. Complet

Re: [HACKERS] PL/pgSQL 2

2014-09-03 7:07 GMT+02:00 Joel Jacobson : > On Wed, Sep 3, 2014 at 12:19 AM, 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 >

Re: [HACKERS] PL/pgSQL 2

On Wed, Sep 3, 2014 at 12:19 AM, 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

Re: [HACKERS] Re: proposal: ignore null fields in not relation type composite type based constructors

2014-09-03 7:05 GMT+02:00 Pavel Stehule : > Hello > > > 2014-09-02 13:54 GMT+02:00 Jeevan Chalke : > > 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 r

Re: [HACKERS] Re: proposal: ignore null fields in not relation type composite type based constructors

Hello 2014-09-02 13:54 GMT+02:00 Jeevan Chalke : > 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, f

Re: [HACKERS] Patch for psql History Display on MacOSX

On Tue, Sep 02, 2014 at 01:56:34AM -0400, Tom Lane wrote: > Noah Misch writes: > > On Mon, Sep 01, 2014 at 10:22:57PM -0400, Tom Lane wrote: > >> Also, as best I can tell, .psql_history files from older libedit versions > >> are not forward-compatible to current libedit versions because of the > >

Re: [HACKERS] Scaling shared buffer eviction

On Wed, Sep 3, 2014 at 9:45 AM, Amit Kapila wrote: > > On Thu, Aug 28, 2014 at 4:41 PM, Amit Kapila wrote: > > > > I have yet to collect data under varying loads, however I have > > collected performance data for 8GB shared buffers which shows > > reasonably good performance and scalability. > >

Re: [HACKERS] Scaling shared buffer eviction

On Thu, Aug 28, 2014 at 4:41 PM, Amit Kapila wrote: > > I have yet to collect data under varying loads, however I have > collected performance data for 8GB shared buffers which shows > reasonably good performance and scalability. > > I think the main part left for this patch is more data for vario

Re: [HACKERS] why after increase the hash table partitions, TPMC decrease

benchmarSQL has about half reads. So I think it should be effective. I don't think BufFreelistLock take much time, it just get a buffer from list. It should be very fast. The test server has 2 CPUs and 12 cores in each CPU. 24 processor totally. CPU Idle time is over 50%. IO only 10%(data is i

Re: [HACKERS] pg_upgrade and epoch

On Wed, Apr 23, 2014 at 12:41:41PM -0700, Sergey Konoplev wrote: > On Wed, Apr 23, 2014 at 5:26 AM, Bruce Momjian wrote: > > Sergey, are you seeing a problem only because you are > > interacting with other systems that didn't reset their epoch? > > I faced this after upgrading clusters with PgQ S

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

Attached revision: * Still doesn't address the open question of whether or not we should optimistically always try "memcmp() == 0" on tiebreak. I still lean towards "yes". * Leaves open the question of what to do when we can't use the abbreviated keys optimization just because a datum tuplesort i

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Tue, Sep 2, 2014 at 12:22 PM, Robert Haas wrote: > Most places that use a SortSupportData initialize ssup.position > explicitly, but tuplesort_begin_datum() doesn't. That's an > inconsistency that should be fixed, but I'm not sure which direction > is best. I'm not sure what you mean. tupleso

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 7:08 PM, Jan Wieck 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. >> > >

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Tue, Sep 2, 2014 at 12:22 PM, Robert Haas wrote: > That would have the > nice property of avoiding the need for special handling in > reversedirection_heap(). Oh, BTW, we probably don't need that anyway, since I'm already disabling abbreviated key optimization in the event of a bounded sort o

Re: [HACKERS] Need Multixact Freezing Docs

On Thu, Aug 28, 2014 at 09:32:17AM -0700, Josh Berkus wrote: > On 08/28/2014 09:09 AM, Alvaro Herrera wrote: > > Josh Berkus wrote: > >> On 04/16/2014 01:30 PM, Alvaro Herrera wrote: > >>> Josh Berkus wrote: > > > You can see the current multixact value in pg_controldata output. Keep > >>

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Tue, Sep 2, 2014 at 12:22 PM, Robert Haas wrote: > Maybe we should get rid of the tiebreak case altogether: the second > SortSupport object is just containing all the same values as the first > one, with only the comparator being different. Can't we just have > both the abbreviated-comparator

Re: [HACKERS] Tips/advice for implementing integrated RESTful HTTP API

On 02/09/14 04:47, Dobes Vandermeer wrote: Same idea as PgBouncer or PgPool. The advantage over hacking PgBouncer/PgPool for the job is that Tomcat can already do a lot of what you want using built-in, pre-existing functionality. Connection pool management, low level REST-st

Re: [HACKERS] PL/pgSQL 2

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 rememb

Re: [HACKERS] PL/pgSQL 2

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

Re: [HACKERS] PL/pgSQL 2

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 ord

Re: [HACKERS] PL/pgSQL 2

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 postg

Re: [HACKERS] why after increase the hash table partitions, TPMC decrease

On Tue, Sep 2, 2014 at 1:39 AM, Xiaoyulei 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 competition. > Can

Re: [HACKERS] PL/pgSQL 2

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

Re: [HACKERS] PL/pgSQL 2

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

Re: [HACKERS] PL/pgSQL 2

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 PostgreSQ

Re: [HACKERS] PL/pgSQL 2

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

Re: [HACKERS] PL/pgSQL 2

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 INTO

Re: [HACKERS] PL/pgSQL 2

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 mailto: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

Re: [HACKERS] PL/pgSQL 2

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 plpgsq

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 02:11 PM, David Johnston wrote: On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake mailto: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 com

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 23:11, David Johnston wrote: On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake >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 compati

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 10:41 AM, Joel Jacobson wrote: On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer 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

Re: [HACKERS] Escaping from blocked send() reprised.

On 2014-09-02 17:21:03 -0400, Tom Lane wrote: > Heikki Linnakangas writes: > > I was going to suggest using WaitLatchOrSocket instead of sleeping in 1 > > second increment, but I see that WaitLatchOrSocket() doesn't currently > > support waiting for a socket to become writeable, without also wai

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 12:20 PM, Joel Jacobson wrote: On Tue, Sep 2, 2014 at 6:09 PM, Kevin Grittner wrote: Joel Jacobson 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

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 10:27 PM, Merlin Moncure 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 the thread. > whe

Re: [HACKERS] Escaping from blocked send() reprised.

Heikki Linnakangas writes: > I was going to suggest using WaitLatchOrSocket instead of sleeping in 1 > second increment, but I see that WaitLatchOrSocket() doesn't currently > support waiting for a socket to become writeable, without also waiting > for it to become readable. I wonder how diffic

Re: [HACKERS] PL/pgSQL 2

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 cou

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 10: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

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake 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 have looked

Re: [HACKERS] PL/pgSQL 2

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 provi

Re: [HACKERS] PL/pgSQL 2

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 ... even

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Tue, Sep 2, 2014 at 12:22 PM, Robert Haas wrote: > < Various points on style> Okay, fair enough. > n_distinct is a cardinality estimate, but AFAIK not using hyperloglog. > What is different about that problem vs. this one that makes each > method correct for its respective case? Or should an

Re: [HACKERS] [BUGS] BUG #10823: Better REINDEX syntax.

Marko Tiikkaja wrote: > On 2014-09-02 22:24, Alvaro Herrera wrote: > >Marko Tiikkaja wrote: > >>Do we have some kind of an agreement on what this patch should look > >>like? Is someone going to prepare an updated patch? Vik? > > > >I think the only issue left for this to be committable is reindex

Re: [HACKERS] [BUGS] BUG #10823: Better REINDEX syntax.

On 2014-09-02 22:24, Alvaro Herrera wrote: Marko Tiikkaja wrote: Do we have some kind of an agreement on what this patch should look like? Is someone going to prepare an updated patch? Vik? I think the only issue left for this to be committable is reindexdb --all previously mentioned. I sc

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 4:04 AM, Joel Jacobson 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 compatibility, at > leas

Re: [HACKERS] [BUGS] BUG #10823: Better REINDEX syntax.

Marko Tiikkaja wrote: > On 2014-08-29 01:00, Alvaro Herrera wrote: > >Note: I don't like the reindexdb UI; if you just run "reindexdb -d > >foobar" it will reindex everything, including system catalogs. I think > >USER TABLES should be the default operation mode for reindex. If you > >want plai

Re: [HACKERS] On partitioning

On Tue, Sep 02, 2014 at 09:44:17AM -0400, Bruce Momjian wrote: > 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 disti

Re: [HACKERS] [BUGS] BUG #10823: Better REINDEX syntax.

On 2014-08-29 01:00, Alvaro Herrera wrote: Vik Fearing wrote: Here are two patches for this. The first one, reindex_user_tables.v1.patch, implements the variant that only hits user tables, as suggested by you. The second one, reindex_no_dbname.v1.patch, allows the three database-wide variants

Re: [HACKERS] PL/pgSQL 2

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

Re: [HACKERS] Scaling shared buffer eviction

On Thu, Aug 28, 2014 at 7:11 AM, Amit Kapila wrote: > I have updated the patch to address the feedback. Main changes are: > > 1. For populating freelist, have a separate process (bgreclaimer) > instead of doing it by bgwriter. > 2. Autotune the low and high threshold values for buffers > in freel

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 07:06:02PM +0200, Joel Jacobson wrote: > On Tue, Sep 2, 2014 at 7:01 PM, Bruce Momjian 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 wrote: > >> > SINGLETON UPDATE ...? > >> > >> Does it come wi

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Tue, Aug 26, 2014 at 4:09 PM, Peter Geoghegan wrote: > On Tue, Aug 26, 2014 at 12:59 PM, Robert Haas wrote: >> I have committed a fix for that problem. Let me know if I missed >> something else. > > Yes, that's all I meant. OK. The patch needs another rebase as a result of that fix. In gen

Re: [HACKERS] Escaping from blocked send() reprised.

On 2014-09-02 21:01:44 +0200, Andres Freund wrote: > I've actually been working on a patch to make the whole interaction with > the client using sockets. The reason I started so is that we lots of far > to complex stuff in signal handlers, and using a latch would allow us to > instead interrupt sen

Re: [HACKERS] Escaping from blocked send() reprised.

On 2014-09-02 21:46:29 +0300, Heikki Linnakangas wrote: > I was going to suggest using WaitLatchOrSocket instead of sleeping in 1 > second increment, but I see that WaitLatchOrSocket() doesn't currently > support waiting for a socket to become writeable, without also waiting for > it to become read

Re: [HACKERS] PL/pgSQL 2

Marko Tiikkaja 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 defaulted

Re: [HACKERS] Escaping from blocked send() reprised.

On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote: - Preventing protocol violation. To prevent protocol violation, secure_write sets ClientConnectionLost when SIGTERM detected, then internal_flush() and ProcessInterrupts() follow the instruction. Oh, hang on. Now that I look at pqcom

Re: [HACKERS] Escaping from blocked send() reprised.

On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote: To make the code mentioned above (Patch 0002) tidy, rewrite the socket emulation code for win32 backends so that each socket can have its own non-blocking state. (patch 0001) The first patch that makes non-blocking sockets behave more sa

Re: [HACKERS] PL/pgSQL 2

On 2014-09-02 19:33, Kevin Grittner wrote: Marko Tiikkaja 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

Re: [HACKERS] PL/PgSQL: RAISE and the number of parameters

Hi, On 2014-09-02 15:04, Heikki Linnakangas wrote: I think this patch has been thoroughly reviewed now. Committed, thanks! Thank you, Heikki. And also big thanks to Fabien for the review! .marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] PL/pgSQL 2

2014-09-02 15:58 GMT+02:00 Marko Tiikkaja : > On 9/2/14 3:52 PM, Joel Jacobson wrote: > >> On Tue, Sep 2, 2014 at 3:41 PM, Heikki Linnakangas >> 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 a

Re: [HACKERS] PL/pgSQL 2

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 wit

Re: [HACKERS] PL/pgSQL 2

Marko Tiikkaja 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 the cod

Re: [HACKERS] PL/pgSQL 2

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 =

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 7:01 PM, Bruce Momjian 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 wrote: >> > SINGLETON UPDATE ...? >> >> Does it come with built-in spell check? :-) It's a bit long to write. >> I like STRICT, th

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 06:57:42PM +0200, Joel Jacobson wrote: > On Tue, Sep 2, 2014 at 6:45 PM, Bruce Momjian 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

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 6:45 PM, Bruce Momjian 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 (pgsql-hackers@postgresql

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 6:31 PM, Heikki Linnakangas 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 rows > with a FOR loo

Re: [HACKERS] PL/pgSQL 2

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 ;". I also think that synt

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 12:40:14AM -0400, Tom Lane wrote: > Craig Ringer 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

Re: [HACKERS] PL/pgSQL 2

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 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

Re: [HACKERS] PL/pgSQL 2

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 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

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 06:27 PM, Joel Jacobson wrote: > On Tue, Sep 2, 2014 at 6:11 PM, Álvaro Hernández Tortosa > 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

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 07:12 PM, Joel Jacobson wrote: On Tue, Sep 2, 2014 at 6:03 PM, Heikki Linnakangas 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 w

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 18:20, Joel Jacobson wrote: On Tue, Sep 2, 2014 at 6:09 PM, Kevin Grittner wrote: Joel Jacobson 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 upd

Re: [HACKERS] PL/pgSQL 2

2014-09-02 18:03 GMT+02:00 Heikki Linnakangas : > On 09/02/2014 06:44 PM, Joel Jacobson wrote: > >> On Tue, Sep 2, 2014 at 5:08 PM, Kevin Grittner wrote: >> >>> Marko Tiikkaja wrote: >>> No, but your code can have a bug. >>> >>> So the main use case is to allow buggy functions which ar

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 6:11 PM, Álvaro Hernández Tortosa 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 saying > they do

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 12:12 PM, Joel Jacobson wrote: On Tue, Sep 2, 2014 at 6:03 PM, Heikki Linnakangas 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 w

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 6:09 PM, Kevin Grittner wrote: > Joel Jacobson 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 exactly one row. Some of t

Re: [HACKERS] PL/pgSQL 2

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 me

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 6:03 PM, Heikki Linnakangas 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 lines of code at alm

Re: [HACKERS] PL/pgSQL 2

Joel Jacobson 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 in the tabl

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 06:44 PM, Joel Jacobson wrote: On Tue, Sep 2, 2014 at 5:08 PM, Kevin Grittner wrote: Marko Tiikkaja 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 no

Re: [HACKERS] PL/pgSQL 2

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 'TRUN

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 5:08 PM, Kevin Grittner wrote: > Marko Tiikkaja 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 primary key column(s) ri

Re: [HACKERS] COPY and heap_sync

On Sun, Aug 31, 2014 at 6:10 AM, Peter Eisentraut 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 to do

Re: [HACKERS] postgresql latency & bgwriter not doing its job

On Tue, Sep 2, 2014 at 8:14 AM, Fabien COELHO 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 you co

Re: [HACKERS] PL/pgSQL 2

On 9/2/14 5:08 PM, Kevin Grittner wrote: Marko Tiikkaja wrote: On 9/2/14 4:26 PM, Kevin Grittner wrote: Joel Jacobson 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

Re: [HACKERS] ALTER SYSTEM RESET?

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

Re: [HACKERS] postgresql latency & bgwriter not doing its job

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 coldly

Re: [HACKERS] PL/pgSQL 2

On Sep 1, 2014, at 10:24 PM, Craig Ringer 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 acceptable to me,

Re: [HACKERS] PL/pgSQL 2

Marko Tiikkaja wrote: > On 9/2/14 4:26 PM, Kevin Grittner wrote: >> Joel Jacobson 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 cas

Re: [HACKERS] postgresql latency & bgwriter not doing its job

On Tue, Aug 26, 2014 at 1:02 AM, Fabien COELHO 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:-) >>> >> >>

Re: [HACKERS] PL/pgSQL 2

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 ad

  1   2   >