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 feedback. I am doubtful about t
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, Stephen Frost > wrote:
> >>> Just a thought. I do still like the general idea of INE support
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 support for
>>> PREPARE, but perhaps there's a better option.
>>
>>
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 some pretty good points here. I guess o
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 in transaction pooli
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 setup?
>
(Kinda a side-track
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 in
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 follow how you can
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 con
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 P
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
cooperatio
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 existing implementations of v3 protoc
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 req
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.
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 be backward and forward compa
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 na
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 token for parse message. But too
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
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 c
> 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 mi
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 [NOT] exists to avoid ha
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:
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 pgsql-h
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 i
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" -> lex/gram on each execution kind
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 stateme
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 suppose, it will not use "pre
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
M
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>> overhead for every time you send that statement. Much better
> Craig>> not to
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> wrapped with an exception handler in case someone
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 send it
Craig>> repeatedly in the first plac
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 upon startup, but curr
> 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
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 -
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 client prepares the stateme
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 cases, we may not be
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 Professional
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 in production a month.
>
No p
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. Done.
>
>
>> 2) All of CINE st
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: http://www.postgresp
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 li
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 usrrptplan (int) IF NOT EXISTS A
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 risk. In addition, we have
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 i
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.
--
Yury
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
--- a/
On Tue, Mar 22, 2016 at 9:53 AM, Andres Freund > 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 availability P
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 pgsq
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 src/backend/commands/prepare.c
isn't enough?
* 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 availability PREPARE it
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 pg_prepared_statements?
> >> I th
* 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?
> >> I think this is not
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 cases, we may not be aw
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. In some cases, we may
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: http://www.postgrespro.co
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: http://www.postgrespro.c
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
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
Postgr
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 popul
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
Cons
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 subscriptio
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 of
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 of
the PREPARE made (pgpool).
Moreover, it seems popular question in the Internet:
http://stackover
63 matches
Mail list logo