po 17. 9. 2018 v 18:24 odesÃlatel Tom Lane napsal:
> "Jonathan S. Katz" writes:
> > Just to chime in real quick: from the perspective of the RMT we did not
> > look at these as a series of "right/wrong" options but what would make
> > the most sense for the v11 release so the community could
"Jonathan S. Katz" writes:
> Just to chime in real quick: from the perspective of the RMT we did not
> look at these as a series of "right/wrong" options but what would make
> the most sense for the v11 release so the community could continue to
> improve support for stored procedures and make it
On Mon, Sep 17, 2018 at 7:45 AM Jonathan S. Katz wrote:
>
> Hi,
>
> On 9/2/18 4:32 PM, Robert Haas wrote:
> > On Thu, Aug 30, 2018 at 4:14 PM, Dave Cramer wrote:
> >> Reading this from the (JDBC) drivers perspective, which is probably a
> >> fairly
> >> popular one,
> >> We now have a standard
On 9/17/18 11:47 AM, Vladimir Sitnikov wrote:
> Merlin>The workaround is to simply not do that and you can get
> Merlin>precise control of behavior
>
> You are absolutely right.
> On top of that, the whole concept of DB-drivers and libpq is useless.
> Users should just simply exchange wire
Merlin>The workaround is to simply not do that and you can get
Merlin>precise control of behavior
You are absolutely right.
On top of that, the whole concept of DB-drivers and libpq is useless.
Users should just simply exchange wire messages for precise control of
behavior.
Vladimir
Hi,
On 9/2/18 4:32 PM, Robert Haas wrote:
> On Thu, Aug 30, 2018 at 4:14 PM, Dave Cramer wrote:
>> Reading this from the (JDBC) drivers perspective, which is probably a fairly
>> popular one,
>> We now have a standard that we can't really support. Either the driver will
>> have to support
>> the
On 30/08/2018 21:35, Robert Haas wrote:
> The semantics you've chosen for procedures are more like Oracle that
> the existing function semantics, which, as I can attest from my work
> experience, can be very useful for users looking to migrate. Worth
> noting, however, is Oracle also has those
On 09/02/18 16:37, Robert Haas wrote:
> On Thu, Aug 30, 2018 at 7:45 PM, Chapman Flack wrote:
>> b to store in y. For any remote client, the result still needs to get
>> back there before the client can apply any "this result gets assigned
>> to my y variable" semantics, and is there any
On Thu, Aug 30, 2018 at 7:45 PM, Chapman Flack wrote:
> On 08/30/18 15:35, Robert Haas wrote:
>> On Tue, Aug 28, 2018 at 6:30 AM, Peter Eisentraut
>> wrote:
>>> CALL compatible with the SQL standard. For example, if you have a
>>> function f1(IN a int, OUT b int), you would call it as SELECT
On Thu, Aug 30, 2018 at 4:14 PM, Dave Cramer wrote:
> Reading this from the (JDBC) drivers perspective, which is probably a fairly
> popular one,
> We now have a standard that we can't really support. Either the driver will
> have to support
> the new PROCEDURE with the {call } mechanism or stay
On 08/30/18 15:35, Robert Haas wrote:
> On Tue, Aug 28, 2018 at 6:30 AM, Peter Eisentraut
> wrote:
>> CALL compatible with the SQL standard. For example, if you have a
>> function f1(IN a int, OUT b int), you would call it as SELECT f1(x)
>> and the "b" would somehow be the return value. But a
>
>
> In other words, being more like the SQL standard is probably good, but
> breaking compatibility is bad. You've technically avoided a
> *backward* compatibility break by deciding that functions and
> procedures can work differently from each other, but that just moves
> the problem around.
On Tue, Aug 28, 2018 at 6:30 AM, Peter Eisentraut
wrote:
> Output parameter handling is not compatible between function calls and
> procedure calls. Our implementation of output parameters in functions
> is an extension of the SQL standard, and while it's been useful, it's
> nonstandard, and I
David>JDBC driver or similar drivers to use the CALL command always from
PG11 on, then the meaning of {call f1(a, b)} will have changed and a
Note: technically speaking, JDBC has two flavours of syntax (however
standard does not clarify the distinction):
S1) {? := call my_proc(?,?) }
S2) { call
On Tuesday, August 28, 2018, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> First of all, what do you want to do with the function return value
> when you use CALL?
> Place it in the result set.
> And would you expect a function that is invoked via CALL to have a
> non-atomic
On 22/08/2018 20:22, Dave Cramer wrote:
> I also agree with David that driver writers made the best out of the
> situation with functions and we are now asking for the server to dual
> purpose the call command.
>
> Is there a technical reason why this is not possible ?
There are several areas of
On Wed, 22 Aug 2018 at 12:58, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 22/08/2018 18:49, David G. Johnston wrote:
> > What others have done doesn't change the situation that has arisen for
> > PostgreSQL due to its implementation history.
>
> What others have done seems
Peter>AFAICT in no case does it involve allowing functions to be called as
procedures or vice versa.
Oracle DB uses the same way to execute both procedures and functions:
pl/sql block.
For instance:
procedure) begin my_proc(); end;
function) begin :result := my_fun(); end;
Call like begin
On 22/08/2018 18:49, David G. Johnston wrote:
> What others have done doesn't change the situation that has arisen for
> PostgreSQL due to its implementation history.
What others have done seems relevant, because the whole reason these
questionable interfaces exist is to achieve compatibility
On Wed, Aug 22, 2018 at 9:39 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 16/08/2018 19:54, Shay Rojansky wrote:
> > I don't think there's anything really Microsoft-specific about any of
> > this (except maybe in the history) - just like JDBC and psycopg, there's
> >
On 16/08/2018 19:54, Shay Rojansky wrote:
> I don't think there's anything really Microsoft-specific about any of
> this (except maybe in the history) - just like JDBC and psycopg, there's
> simply a single standard way in the database API for invoking
> server-side things, and not two ways.
Have
On Thu, 16 Aug 2018 at 13:54, Shay Rojansky wrote:
> Peter,
>
> I think this is all coming from Microsoft. The JDBC driver API was
>> modeled after the ODBC API, and the ODBC specification also contains the
>> {call} escape. Microsoft SQL Server is also the only SQL implementation
>> to handle
Peter,
I think this is all coming from Microsoft. The JDBC driver API was
> modeled after the ODBC API, and the ODBC specification also contains the
> {call} escape. Microsoft SQL Server is also the only SQL implementation
> to handle this stored function/procedure stuff totally differently:
Hi,
On 2018-08-16 20:08:20 +0300, Vladimir Sitnikov wrote:
> Shay>On the other hand, releasing *without* this also has its consequence,
> namely setting in stone that the database-independent language API cannot
> be used for invoking the new stored procedures
> Shay>So I hope you at least
Shay>On the other hand, releasing *without* this also has its consequence,
namely setting in stone that the database-independent language API cannot
be used for invoking the new stored procedures
Shay>So I hope you at least consider going through the thought process
about allowing this.
+1
I
Peter>I am familiar with the Java {call} escape. But I think it's pretty
Peter>useless. You're not going to get any compatibility with anything from
Peter>it, since every SQL implementation does something different with it
Would you please be more specific?
{ call ... } converts the SQL to the
On 16/08/2018 00:50, Shay Rojansky wrote:
> >> Also another request by Vladimir and myself to consider allowing
> >> functions to be invoked with CALL, in order to provide a single way to
> >> call both procedures and functions - this is important as language
> >> database APIs
> Well, no, actually I think it wouldn't. Multiple rowsets coming back
> from a single query is, to my mind anyway, forbidden in the extended query
> mode. Yeah, we could probably get away with it in simple query mode
> (PQexec), but it's very likely to break clients in extended mode, because
>
Peter Eisentraut writes:
> On 12/08/2018 09:51, Shay Rojansky wrote:
>> Would it be possible for you to review the following two questions? Some
>> assertions have been made in this thread about the new stored procedures
>> (support for dynamic and multiple resultsets) whose compatibility with
>>
On 12/08/2018 09:51, Shay Rojansky wrote:
> Would it be possible for you to review the following two questions? Some
> assertions have been made in this thread about the new stored procedures
> (support for dynamic and multiple resultsets) whose compatibility with
> the current PostgreSQL protocol
> On Aug 14, 2018, at 1:30 PM, Andres Freund wrote:
>
> Hi,
>
> On 2018-08-12 08:51:28 +0100, Shay Rojansky wrote:
>> Peter, Tom,
>>
>> Would it be possible for you to review the following two questions? Some
>> assertions have been made in this thread about the new stored procedures
>>
Hi,
On 2018-08-12 08:51:28 +0100, Shay Rojansky wrote:
> Peter, Tom,
>
> Would it be possible for you to review the following two questions? Some
> assertions have been made in this thread about the new stored procedures
> (support for dynamic and multiple resultsets) whose compatibility with
Peter, Tom,
Would it be possible for you to review the following two questions? Some
assertions have been made in this thread about the new stored procedures
(support for dynamic and multiple resultsets) whose compatibility with the
current PostgreSQL protocol are unclear to me as a client driver
On Sat, Aug 04, 2018 at 07:03:47AM +0100, Shay Rojansky wrote:
> > Shay>Npgsql currently always sends a describe as part of statement
> > execution (for server-prepared messages the describe is done only once, at
> > preparation-time). Vladimir, are you doing things differently here?
> >
> > The
Shay Rojansky wrote:
> In one way that's good, but I wonder how this squares with the following
> written by David above:
> > 1. A stored procedure should be able to return multiple resultsets with
> different structures.
> > 2. A stored procedure can decide dynamically of the structure
> Shay>Npgsql currently always sends a describe as part of statement
> execution (for server-prepared messages the describe is done only once, at
> preparation-time). Vladimir, are you doing things differently here?
>
> The same thing is for pgjdbc. It does use describe to identify result row
>
Shay>Npgsql currently always sends a describe as part of statement
execution (for server-prepared messages the describe is done only once, at
preparation-time). Vladimir, are you doing things differently here?
The same thing is for pgjdbc. It does use describe to identify result row
format.
Apologies for disappearing from this conversation for a week.
First off, on the .NET side I have the exact same issue that Vladimir
Sitnikov described for the Java side. The .NET database API (ADO.NET) has a
standard, portable way for calling "server-side code". Since stored
procedures are in
On Tue, Jul 24, 2018 at 11:31 AM, Daniel Verite
wrote:
> David G. Johnston wrote:
>
> > > 2. A stored procedure can decide dynamically of
> > > the structure of the resultset(s) it returns,
> > > and the caller will discover it as they're returned, not
> > > before.
> > >
> >
> > The
David G. Johnston wrote:
> > 2. A stored procedure can decide dynamically of
> > the structure of the resultset(s) it returns,
> > and the caller will discover it as they're returned, not
> > before.
> >
>
> The function itself doesn't care - this concern is about SELECT vs CALL
>
>to compensate for the decisions made by the JDBC driver PostgreSQL
It is not a decision by PostgreSQL JDBC driver. It is a decision by JDBC
(Java Database Connectivity) specification itself.
pgjdbc just follows the specification there.
Well, there's an initiative for a new JDBC specification
On Mon, Jul 23, 2018 at 12:07 PM, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> 2) Just a side note: `CALL my_proc()` is not suitable for functions. That
> looks weird.
> Is the client expected to lookup system catalogs in order to tell if
> `my_proc` is procedure or function and use
On Tue, Jul 24, 2018 at 6:58 AM, Daniel Verite
wrote:
> Vladimir Sitnikov wrote:
>
> > There's no notion if the called object is a procedure or function.
> > Note: PostgreSQL can have a function that `returns void`, and it is hard
> to
> > tell if {call test()} refers to a function or
Vladimir Sitnikov wrote:
> There's no notion if the called object is a procedure or function.
> Note: PostgreSQL can have a function that `returns void`, and it is hard to
> tell if {call test()} refers to a function or procedure.
>
> Can functions and procedures be unified at the
On 23.07.18 19:38, Andrew Gierth wrote:
>> "Robert" == Robert Haas writes:
>
> >> However, connecting via Npgsql, which uses the extended protocol, I
> >> see something quite different. As a response to a Describe
> >> PostgreSQL message, I get back a NoData response rather than a
> >>
Andrew>does it fail on the latest 11-stable
1) Current "build from Git/master PostgreSQL" produces the data row for
both simple and extended queries.
2) Just a side note: `CALL my_proc()` is not suitable for functions. That
looks weird.
Is the client expected to lookup system catalogs in order
> "Robert" == Robert Haas writes:
>> However, connecting via Npgsql, which uses the extended protocol, I
>> see something quite different. As a response to a Describe
>> PostgreSQL message, I get back a NoData response rather than a
>> RowDescription message, In other words, it would
On Mon, Jul 23, 2018 at 2:23 AM, Shay Rojansky wrote:
> Hi hackers, I've encountered some odd behavior with the new stored procedure
> feature, when using INOUT parameters, running PostgreSQL 11-beta2.
>
> With the following procedure:
>
> CREATE OR REPLACE PROCEDURE my_proc(INOUT results text)
>
Hi hackers, I've encountered some odd behavior with the new stored
procedure feature, when using INOUT parameters, running PostgreSQL 11-beta2.
With the following procedure:
CREATE OR REPLACE PROCEDURE my_proc(INOUT results text)
LANGUAGE 'plpgsql'
AS $BODY$
BEGIN
select 'test' into results;
49 matches
Mail list logo
