Re: [HACKERS] NOT EXIST for PREPARE

On Sun, Jun 5, 2016 at 11:33 AM, David G. Johnston wrote: > As an aside; most (all?) of our INEs apply to persistent schema objects. > Extending that to session objects is a conceptual leap. There is close to no activity here, so I marked the patch as returned with

Re: [HACKERS] NOT EXIST for PREPARE

On Friday, May 6, 2016, Robert Haas wrote: > On Fri, May 6, 2016 at 2:38 PM, Merlin Moncure > wrote: > > On Fri, Mar 25, 2016 at 8:36 AM, Merlin Moncure > wrote: > >> On Wed, Mar 23, 2016 at 3:10 PM,

Re: [HACKERS] NOT EXIST for PREPARE

On Fri, May 6, 2016 at 2:38 PM, Merlin Moncure wrote: > On Fri, Mar 25, 2016 at 8:36 AM, Merlin Moncure wrote: >> On Wed, Mar 23, 2016 at 3:10 PM, Stephen Frost wrote: >>> Just a thought. I do still like the general idea of INE

Re: [HACKERS] NOT EXIST for PREPARE

On Fri, Mar 25, 2016 at 8:36 AM, Merlin Moncure wrote: > On Wed, Mar 23, 2016 at 3:10 PM, Stephen Frost wrote: >> Just a thought. I do still like the general idea of INE support for >> PREPARE, but perhaps there's a better option. > > Admittedly, you make

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 3:10 PM, Stephen Frost wrote: > Merlin, > > * Merlin Moncure (mmonc...@gmail.com) wrote: >> No one is arguing that that you should send it any every time (at >> least -- I hope not). > > I'm not sure I follow how you can avoid that though? > > pgbouncer

Re: [HACKERS] NOT EXIST for PREPARE

On 24 March 2016 at 23:13, Vladimir Sitnikov wrote: > > >doesn't have any kind of capabilities negotiation > > Do you think capability negotiation should indeed be at the protocol level? > What's wrong with say "select * from backend_capabilities" at the > connection

Re: [HACKERS] NOT EXIST for PREPARE

On 03/24/2016 11:21 PM, Merlin Moncure wrote: Personally I think the right solution would be to add support for prepared statements in pgbouncer, and have pgbouncer run PREPARE as necessary, either after opening a new connection to the database or at the first use of a given prepared statement

Re: [HACKERS] NOT EXIST for PREPARE

On Thu, Mar 24, 2016 at 2:52 PM, Andreas Karlsson wrote: > On 03/23/2016 09:10 PM, Stephen Frost wrote: >> >> * Merlin Moncure (mmonc...@gmail.com) wrote: >>> >>> No one is arguing that that you should send it any every time (at >>> least -- I hope not). >> >> >> I'm not sure I

Re: [HACKERS] NOT EXIST for PREPARE

On 03/23/2016 09:10 PM, Stephen Frost wrote: * Merlin Moncure (mmonc...@gmail.com) wrote: No one is arguing that that you should send it any every time (at least -- I hope not). I'm not sure I follow how you can avoid that though? pgbouncer in transaction pooling mode may let a particular

Re: [HACKERS] NOT EXIST for PREPARE

Tom Lane wrote: because it would break applications I still do not agree with this. The app expects that there can be no mistakes and it does not happen. I can not invent a situation when it is breaks. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian

Re: [HACKERS] NOT EXIST for PREPARE

Tom> Not to mention that the whole idea of that being a semantically Tom> significant property of a name is a monstrous kluge. You are right here. Just in case, Marko Kreen says (see [1]) pgbouncer has all the information required to remap statement names, so he says pgbouncer needs no

Re: [HACKERS] NOT EXIST for PREPARE

Vladimir Sitnikov writes: > Tom>If you think that's not a protocol change, you are mistaken. It > Tom>changes a behavior that's specified in the protocol documentation. > Even if it requires documentation, this particular change will work seamlessly > across

Re: [HACKERS] NOT EXIST for PREPARE

Tom>If you think that's not a protocol change, you are mistaken. It Tom>changes a behavior that's specified in the protocol documentation. Even if it requires documentation, this particular change will work seamlessly across existing implementations of v3 protocol. For instance, it would not

Re: [HACKERS] NOT EXIST for PREPARE

Vladimir Sitnikov wrote: Just to be clear: I'm not fond of encoding the answer to the universe into statement name. However, I find that "name convention" a smart invention. I forgot one more decision: add GUC variable. A little fatty for this but not touch the protocol and easy to implement.

Re: [HACKERS] NOT EXIST for PREPARE

Vladimir Sitnikov writes: > Craig>I really, really doubt you can change this before we do a > protocol version bump. > Technically speaking, the idea of using first bytes of statement name > to convey extra information does not require protocol version bump. It > can

Re: [HACKERS] NOT EXIST for PREPARE

Craig>I really, really doubt you can change this before we do a protocol version bump. Technically speaking, the idea of using first bytes of statement name to convey extra information does not require protocol version bump. It can be backward and forward compatible. For instance: if statement

Re: [HACKERS] NOT EXIST for PREPARE

On 24 March 2016 at 20:03, Yury Zhuravlev wrote: > I have a big question. What need to do with message protocol? > If we write name in Parse message we store prepared statement. I see some > solutions for this problem but all not ideal: > 1. We can add second char

Re: [HACKERS] NOT EXIST for PREPARE

I have a big question. What need to do with message protocol? If we write name in Parse message we store prepared statement. I see some solutions for this problem but all not ideal: 1. We can add second char token for parse message. But too serious change. 2. We can try add parameter to tail of

Re: [HACKERS] NOT EXIST for PREPARE

Michael Meskes wrote: While ecpg may not be the choice for new applications, there are a lot of legacy applications out there that need ecpg to be migrated to PostgreSQL. 2016 is a good time to rewrite them. ;) I think Postgres will be more likely if it would be a little less concerned about

Re: [HACKERS] NOT EXIST for PREPARE

> I want to understand the situation. You may want to make the build > ecpg  > optional. Personally, I want to. You lost me here, sorry. What exactly do you want to do?  While ecpg may not be the choice for new applications, there are a lot of legacy applications out there that need ecpg to be

Re: [HACKERS] NOT EXIST for PREPARE

On 24 March 2016 at 02:01, Merlin Moncure wrote: > > If you plan to have "prepare if not exists" at startup only, why don't > > you just wrap it with > > exception handler then? > > That's impolite to our users. Virtually all other commands have been > decorated with IF

Re: [HACKERS] NOT EXIST for PREPARE

Michael Meskes wrote: More than you think. I doubt you want to propose removing features that make developing new features harder, or do you? :) I want to understand the situation. You may want to make the build ecpg optional. Personally, I want to. -- Yury Zhuravlev Postgres Professional:

Re: [HACKERS] NOT EXIST for PREPARE

Merlin> All I'm saying is that the use of Merlin> server side prepared statements is extremely problematic in Merlin> conjunction with pgbouncer I've filed https://github.com/pgbouncer/pgbouncer/issues/126 to get pgbouncer improved in regard to prepared statements. Vladimir -- Sent via

Re: [HACKERS] NOT EXIST for PREPARE

Merlin, * Merlin Moncure (mmonc...@gmail.com) wrote: > No one is arguing that that you should send it any every time (at > least -- I hope not). I'm not sure I follow how you can avoid that though? pgbouncer in transaction pooling mode may let a particular connection die off and then, when you

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 2:17 PM, Vladimir Sitnikov wrote: > Merlin>proposed would allow use of server side prepared statements with JDBC. > > It would not. If we discuss end-to-end scenarios in detail, we would end up > with > "send full query on each execution" ->

Re: [HACKERS] NOT EXIST for PREPARE

Merlin>proposed would allow use of server side prepared statements with JDBC. It would not. If we discuss end-to-end scenarios in detail, we would end up with "send full query on each execution" -> lex/gram on each execution kind of overheads. That is hardly a proper way of using prepared

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 1:15 PM, Vladimir Sitnikov wrote: > Merlin>No one is arguing that that you should send it any every time (at > least -- I hope not). > > Well, what is your suggestion exactly? > > pgjdbc is NOT using "prepare ..." sql command. > I'm inclined to

Re: [HACKERS] NOT EXIST for PREPARE

Merlin>No one is arguing that that you should send it any every time (at least -- I hope not). Well, what is your suggestion exactly? pgjdbc is NOT using "prepare ..." sql command. I'm inclined to suppose, it will not use "prepare..." even after your fix. Merlin>Again, not in pooling scenarios

Re: [HACKERS] NOT EXIST for PREPARE

Vladimir Sitnikov writes: > 2016-03-23 16:21 GMT+03:00 Merlin Moncure : >> On Wed, Mar 23, 2016 at 7:27 AM, Craig Ringer wrote: > Craig>> With PREPARE IF NOT EXISTS the client is also paying parse and network > Craig>>

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 12:46 PM, Vladimir Sitnikov wrote: > 2016-03-23 16:21 GMT+03:00 Merlin Moncure : > Merlin> A typical pattern is for the application to > Merlin> prepare them all upon startup, but currently each PREPARE needs to be > Merlin>

Re: [HACKERS] NOT EXIST for PREPARE

2016-03-23 16:21 GMT+03:00 Merlin Moncure : > On Wed, Mar 23, 2016 at 7:27 AM, Craig Ringer wrote: Craig>> With PREPARE IF NOT EXISTS the client is also paying parse and network Craig>> overhead for every time you send that statement. Much better not to

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 8:21 AM, Merlin Moncure wrote: > I'm not understanding the objection at all. You have N client > sessions connecting to the database that all utilize the same named > prepared statement. A typical pattern is for the application to > prepare them all

Re: [HACKERS] NOT EXIST for PREPARE

> PS Who use ecpg? For me it's like hell.  More than you think. I doubt you want to propose removing features that make developing new features harder, or do you? :) Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot

Re: [HACKERS] NOT EXIST for PREPARE

Fabrízio de Royes Mello wrote: I got an error when build this patch. I fix it! All tests pass (include ecpg tests). Patch in attachment. Thanks. PS Who use ecpg? For me it's like hell. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Companydiff

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 7:27 AM, Craig Ringer wrote: > With PREPARE IF NOT EXISTS the client is also paying parse and network > overhead for every time you send that statement. Much better not to send it > repeatedly in the first place. How did you determine that? The

Re: [HACKERS] NOT EXIST for PREPARE

On 22 March 2016 at 21:01, Andres Freund wrote: > Hi, > > > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote: > > Do I understand correctly the only way know availability PREPARE it will > > appeal to pg_prepared_statements? > > I think this is not a good practice. In some

Re: [HACKERS] NOT EXIST for PREPARE

Fabrízio de Royes Mello wrote: I got an error when build this patch. Thanks for review and tests! I'm working on it. Without ecpg everything works fine. In ecpg we have black perl magic and special rules for PREPARE. The error is in perl script. Regards -- Yury Zhuravlev Postgres

Re: [HACKERS] NOT EXIST for PREPARE

On Tue, Mar 22, 2016 at 6:16 PM, Yury Zhuravlev wrote: > > Fabrízio de Royes Mello wrote: >> >> >> You're correct. Yury please add your patch to the next commitfest. > > Done. But I do not have restrictions as part of our PostgresPro distr. I think this patch will be

Re: [HACKERS] NOT EXIST for PREPARE

On Tue, Mar 22, 2016 at 6:04 PM, Yury Zhuravlev wrote: > > I was not sure about the syntax, so this was a prototype. Now, like all completed yet. > >> >> 1) I think this syntax is wrong... Instead the common should be: >> >> PREPARE [IF NOT EXISTS] ... > > You right.

Re: [HACKERS] NOT EXIST for PREPARE

Fabrízio de Royes Mello wrote: You're correct. Yury please add your patch to the next commitfest. Done. But I do not have restrictions as part of our PostgresPro distr. I think this patch will be in production a month. Big Thanks. -- Yury Zhuravlev Postgres Professional:

Re: [HACKERS] NOT EXIST for PREPARE

I was not sure about the syntax, so this was a prototype. Now, like all completed yet. 1) I think this syntax is wrong... Instead the common should be: PREPARE [IF NOT EXISTS] ... You right. Done. 2) All of CINE statements we emit a NOTICE skipping message, so you should emit a message

Re: [HACKERS] NOT EXIST for PREPARE

On Tue, Mar 22, 2016 at 2:19 PM, Yury Zhuravlev wrote: > > Yury Zhuravlev wrote: >>> >>> You already have a patch? If yes I'm glad to review it. >>> >> Please. Patch in attachment. > > > Fix bug, forgot change attr number in parser. And, I forgot example: > PREPARE

Re: [HACKERS] NOT EXIST for PREPARE

On Tue, Mar 22, 2016 at 2:32 PM, Alvaro Herrera wrote: > > Yury Zhuravlev wrote: > > Fabrízio de Royes Mello wrote: > > >You already have a patch? If yes I'm glad to review it. > > > > If the community is not against it, I'll do it quickly. Changing the syntax > > is the

Re: [HACKERS] NOT EXIST for PREPARE

Yury Zhuravlev wrote: > Fabrízio de Royes Mello wrote: > >You already have a patch? If yes I'm glad to review it. > > If the community is not against it, I'll do it quickly. Changing the syntax > is the risk. In addition, we have already missed 9.6. Also we're in the middle of a commitfest, and

Re: [HACKERS] NOT EXIST for PREPARE

Yury Zhuravlev wrote: You already have a patch? If yes I'm glad to review it. Please. Patch in attachment. Fix bug, forgot change attr number in parser. And, I forgot example: PREPARE usrrptplan (int) IF NOT EXISTS AS SELECT * FROM pg_operator; PREPARE New patch in attachment. --

Re: [HACKERS] NOT EXIST for PREPARE

You already have a patch? If yes I'm glad to review it. Please. Patch in attachment. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Companydiff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c index cec37ce..63d164f 100644 ---

Re: [HACKERS] NOT EXIST for PREPARE

Fabrízio de Royes Mello wrote: Skip error if already exists when catched in src/backend/commands/prepare.c isn't enough? I think that's enough. And expand PrepareStmt of course. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via

Re: [HACKERS] NOT EXIST for PREPARE

On Tue, Mar 22, 2016 at 11:50 AM, Stephen Frost wrote: > > I agree that PREPARE IF NOT EXISTS would be nice to have, but only if we > can keep it fast somehow, which is the part that makes me wonder a bit. > Skip error if already exists when catched in

Re: [HACKERS] NOT EXIST for PREPARE

* Andres Freund (and...@anarazel.de) wrote: > On 2016-03-22 09:37:15 -0500, Merlin Moncure wrote: > > On Tue, Mar 22, 2016 at 8:01 AM, Andres Freund wrote: > > > Hi, > > > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote: > > >> Do I understand correctly the only way know

Re: [HACKERS] NOT EXIST for PREPARE

On 2016-03-22 09:37:15 -0500, Merlin Moncure wrote: > On Tue, Mar 22, 2016 at 8:01 AM, Andres Freund wrote: > > Hi, > > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote: > >> Do I understand correctly the only way know availability PREPARE it will > >> appeal to

Re: [HACKERS] NOT EXIST for PREPARE

* Merlin Moncure (mmonc...@gmail.com) wrote: > On Tue, Mar 22, 2016 at 8:01 AM, Andres Freund wrote: > > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote: > >> Do I understand correctly the only way know availability PREPARE it will > >> appeal to pg_prepared_statements? >

Re: [HACKERS] NOT EXIST for PREPARE

On Tue, Mar 22, 2016 at 8:01 AM, Andres Freund wrote: > Hi, > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote: >> Do I understand correctly the only way know availability PREPARE it will >> appeal to pg_prepared_statements? >> I think this is not a good practice. In some

Re: [HACKERS] NOT EXIST for PREPARE

On Tue, Mar 22, 2016 at 10:01 AM, Andres Freund wrote: > > Hi, > > > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote: > > Do I understand correctly the only way know availability PREPARE it will > > appeal to pg_prepared_statements? > > I think this is not a good practice.

Re: [HACKERS] NOT EXIST for PREPARE

Yury Zhuravlev wrote: It may be necessary to add an index on the field "statement"? Sorry. Said nonsense. We need to understand what kind of behavior should be if the name is the same but query_string not? Replace? Thanks. -- Yury Zhuravlev Postgres Professional:

Re: [HACKERS] NOT EXIST for PREPARE

Fabrízio de Royes Mello wrote: You already have a patch? If yes I'm glad to review it. If the community is not against it, I'll do it quickly. Changing the syntax is the risk. In addition, we have already missed 9.6. Thanks. -- Yury Zhuravlev Postgres Professional:

Re: [HACKERS] NOT EXIST for PREPARE

On 2016-03-22 16:51:26 +0300, Yury Zhuravlev wrote: > Andres Freund wrote: > >you'd still need to compare the > >statement somehow > > You right, I think about that as syntax sugar. Maybe with some performance > increase but hardly. We can save on a round trip. If anything what'd be useful would

Re: [HACKERS] NOT EXIST for PREPARE

Andres Freund wrote: you'd still need to compare the statement somehow You right, I think about that as syntax sugar. Maybe with some performance increase but hardly. We can save on a round trip. It may be necessary to add an index on the field "statement"? Thanks. -- Yury Zhuravlev

Re: [HACKERS] NOT EXIST for PREPARE

Hi, On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote: > Do I understand correctly the only way know availability PREPARE it will > appeal to pg_prepared_statements? > I think this is not a good practice. In some cases, we may not be aware of > the PREPARE made (pgpool). Moreover, it seems

Re: [HACKERS] NOT EXIST for PREPARE

Em terça-feira, 22 de março de 2016, Yury Zhuravlev < u.zhurav...@postgrespro.ru> escreveu: > Fabrízio de Royes Mello wrote: > >> I think you meant IF NOT EXISTS, right? >> > Thanks, you right. > > You already have a patch? If yes I'm glad to review it. Regards, -- Fabrízio de Royes Mello

Re: [HACKERS] NOT EXIST for PREPARE

Fabrízio de Royes Mello wrote: I think you meant IF NOT EXISTS, right? Thanks, you right. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] NOT EXIST for PREPARE

Em terça-feira, 22 de março de 2016, Yury Zhuravlev < u.zhurav...@postgrespro.ru> escreveu: > Hello hackers. > > Do I understand correctly the only way know availability PREPARE it will > appeal to pg_prepared_statements? > I think this is not a good practice. In some cases, we may not be aware