Quoth the JDBC spec:
public interface CallableStatement
extends PreparedStatement
The interface used to execute SQL stored procedures. The JDBC API provides a
stored procedure SQL escape syntax that allows stored procedures to be called
in a standard way for all RDBMSs. This escape syntax has
There's a bunch of very ugly code in backend/main/main.c that involves
the preprocessor constants NOFIXADE and NOPRINTADE. The code seems
to be related to support for Alpha and/or ultrix4. NOFIXADE is defined
by port/osf.h and port/ultrix4.h, while NOPRINTADE is not defined as far
as I can tell
On Thu, 23 Sep 2004, Grant Finnemore wrote:
Quoth the JDBC spec:
public interface CallableStatement
extends PreparedStatement
The interface used to execute SQL stored procedures. The JDBC API provides a
stored procedure SQL escape syntax that allows stored procedures to be called
in a
IN parameter values are set using the set methods inherited from
PreparedStatement. The type of all OUT parameters must be
registered
prior to executing the stored procedure; their values are retrieved
after execution via the get methods provided here.
A CallableStatement can
On N, 2004-09-23 at 06:41, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
We were bitten by the following bug a few times, when our server tried
to reestablish connections under bad network conditions:
if connection is closed while trying to get response to SSL setup packet
Gavin Sherry wrote:
I don't get this multiple ResultSet stuff. All I can think of is that the
spec has this in mind:
CallableStatement cstmt = conn.prepareCall({call foo(); call bar();});
or
CallableStatement cstmt = conn.prepareCall({call foo()} {call bar();});
or some other permutation.
It's not
Hi Magnus,
Yes, this is the situation that I have been thinking about. Specifically
when a single stored procedure returns many recordsets.
Perhaps I should also clarify that the spec I have been using is
the JDK javadoc documentation.
Using java with Magnus' procedure:
CallableStatement cs =
On Thu, 23 Sep 2004, Oliver Jowett wrote:
Gavin Sherry wrote:
I don't get this multiple ResultSet stuff. All I can think of is that the
spec has this in mind:
CallableStatement cstmt = conn.prepareCall({call foo(); call bar();});
or
CallableStatement cstmt =
On N, 2004-09-23 at 11:34, Grant Finnemore wrote:
Hi Magnus,
Yes, this is the situation that I have been thinking about. Specifically
when a single stored procedure returns many recordsets.
IIRC support for returning multiple recordsets was removed from
postgresql fe-be protocol years ago as
Problem:
PL/Java use a JVM. On some platforms and with some JVM's (Sun's in
particular) a libzip.so is bundled that contains a 1.1.3 version of
functions also provided in zlib (why they do this is beyond me, but they
do so I'll have to live with it). PostgreSQL is linked with zlib by
default.
Laszlo,
Tom, is there other way in pg 7.4 than backporting PG_TRY? It seems a lot
of work.
I have the needed macros implemented for 7.4 in PL/Java. Look in
src/C/pljava.h.
The exception handling in versions prior to 8.0 is very rudimentary
though. There's (as you already discovered) no way to
Am Donnerstag, 23. September 2004 13:02 schrieb Thomas Hallgren:
From what I can understand from the documentation, the only utility in
PostgreSQL that actually uses zlib is pg_dump? If so, why is the
postgres process linked with -lz?
Because we are too lazy to fine-tune the build system for
Peter Eisentraut wrote:
Because we are too lazy to fine-tune the build system for cases like
this.
The best solution would be to build zlib with symbol versioning.
I'm not so sure. I think zlib is a commodity on most systems. You don't
want to build it at all. Perhaps if I submit a patch
Hannu Krosing wrote:
On N, 2004-09-23 at 11:34, Grant Finnemore wrote:
Hi Magnus,
Yes, this is the situation that I have been thinking about. Specifically
when a single stored procedure returns many recordsets.
IIRC support for returning multiple recordsets was removed from
postgresql
On N, 2004-09-23 at 15:22, Peter Mount wrote:
Hannu Krosing wrote:
On N, 2004-09-23 at 11:34, Grant Finnemore wrote:
Hi Magnus,
Yes, this is the situation that I have been thinking about. Specifically
when a single stored procedure returns many recordsets.
IIRC support
Hannu Krosing wrote:
On N, 2004-09-23 at 15:22, Peter Mount wrote:
Hannu Krosing wrote:
On N, 2004-09-23 at 11:34, Grant Finnemore wrote:
Hi Magnus,
Yes, this is the situation that I have been thinking about. Specifically
when a single stored procedure returns many recordsets.
Peter Eisentraut wrote:
Am Donnerstag, 23. September 2004 13:02 schrieb Thomas Hallgren:
From what I can understand from the documentation, the only utility in
PostgreSQL that actually uses zlib is pg_dump? If so, why is the
postgres process linked with -lz?
Because we are too lazy to
No idea. That code came in at a time when we weren't as good at
documenting platform-specific stuff. (We never expected to be this
popular or to be playing with this code 8 years later.) :-)
I just found this:
http://joshua.raleigh.nc.us/docs/linux-2.4.10_html/87660.html
Want to
Hannu Krosing [EMAIL PROTECTED] writes:
One possibility is to forget the direct call to recv() and use
pqReadData --- since conn-ssl isn't set yet, and we aren't expecting
the server to send more than one byte, this should in theory be safe.
I was scared by the comment before recv(...,1,0)
Neil Conway [EMAIL PROTECTED] writes:
Does anyone have any idea what this code is intended to do, and why it
is necessary?
A bit of googling (I used SSIN_UACPROC) will turn up enough info to
clue you in. Apparently, on these machines an unaligned memory access
causes a trap to the kernel, but
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 23. September 2004 13:02 schrieb Thomas Hallgren:
From what I can understand from the documentation, the only utility in
PostgreSQL that actually uses zlib is pg_dump? If so, why is the
postgres process linked with -lz?
Because we are
Hannu Krosing [EMAIL PROTECTED] writes:
IIRC support for returning multiple recordsets was removed from
postgresql fe-be protocol years ago as nobody ever needs it ;)
The protocol can still do it, and so can the backend, but it will
certainly break most if not all clients. Here's an example:
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 23. September 2004 13:02 schrieb Thomas Hallgren:
From what I can understand from the documentation, the only utility in
PostgreSQL that actually uses zlib is pg_dump? If so, why is the
postgres process linked with
Gavin Sherry wrote:
Do you have any idea about databases returning result sets from SQL
procedures (ie, not functions).
As other's have pointed out, this is very common in the MS SQL Server
world (and I believe Sysbase also supports it). It works like:
begin proc def
select * from something
...
Dear Tom,
When I wrote that, I was trying to assume as little as possible about
the SSL protocol. The only way there could be a problem is if the
server is first to send during the SSL negotiation handshake; which
seems odd but not impossible. Anyone know for sure?
As for the RFC, the
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm not sure I understand why keeping track of what we need for each
executable is such a difficult task, though. I count 23 executables and
a handful of libraries. Is this such a herculean task?
Handful? I count 32 AC_CHECK_LIB and AC_SEARCH_LIBS
Fabien COELHO [EMAIL PROTECTED] writes:
Now if you connect to some other server with some other protocol, that is
another issue...
But the code in question is only for SSL connection to PG, so that's
a red herring I think.
Also, I do not know how the postgresql protocol interacts
with SSL...
Gavin Sherry [EMAIL PROTECTED] writes:
3) Procedures can be run in the same savepoint level as the caller when
OLD SAVEPOINT LEVEL is specified at creation time. According to SQL2003,
functions must be run on a new savepoint level. From my understanding, we
do not do this currently.
It's
Gavin, Neil,
Following is a proposal to implement what SQL2003 calls 'SQL-Invoked
Procedures' and what most people refer to as stored procedures. Fujitsu
will be funding Neil Conway and I to work on this feature.
Which, by the way, is way keen.
My comments are based on having professionally
Folks,
Just noticed -- the hard way -- that running ALTER TABLE ... SET STATISTICS
requires a full table lock.I can't think of any practical reason why SET
STATISTICS would need to lock the table; presumably this is just because it's
an ALTER TABLE statement?If so, maybe we should
On Thu, Sep 23, 2004 at 12:40:41PM -0400, Tom Lane wrote:
What I'd like to see is a procedure capability which is somehow
outside the transaction system and can therefore invoke BEGIN, COMMIT,
SAVEPOINT, etc. I have no immediate ideas about how to do this, but
I think that's what people are
Tom Lane wrote:
regression=# create rule r1 as on insert to surprise do
regression-# ( select 'hello' ; select 'how are you' );
CREATE RULE
The 'hello' result was in fact computed and sent by the backend, but it
was discarded in libpq (see the documentation about PQexec: only the
last resultset
Oliver Jowett [EMAIL PROTECTED] writes:
The JDBC driver currently sends Describe/Execute and expects exactly one
of RowDescription/NoData followed by zero or more DataRows followed by
one of CommandComplete/EmptyQueryResponse/PortalSuspended. This seems
wrong if there could be multiple
Tom Lane wrote:
How can clients distinguish multiple resultsets if they're using the
extended query protocol?
You'll get multiple repetitions of RowDescription/DataRows.
Ah, so the Execute spontaneously generates a RowDescription
spontaneously when it hits the second resultset, without needing
Alvaro Herrera [EMAIL PROTECTED] writes:
What's needed for this is to isolate the transaction-initiating code
from the main query-processing loop. So for CALL statements it wouldn't
be invoked, and the procedure would be able to use its own explicit
transaction blocks and savepoints.
Is
Oliver Jowett [EMAIL PROTECTED] writes:
Tom Lane wrote:
How can clients distinguish multiple resultsets if they're using the
extended query protocol?
You'll get multiple repetitions of RowDescription/DataRows.
Ah, so the Execute spontaneously generates a RowDescription
spontaneously
[EMAIL PROTECTED] (Dominic Mitchell) writes:
On Thu, Sep 23, 2004 at 04:37:52PM -0400, Tom Lane wrote:
That last statement is not actually correct, is it? AFAICS we do tell
SSL to enforce certificates if we find a valid root.crt file.
According to the docs[1], you also need
Greg Stark [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
What's needed for this is to isolate the transaction-initiating code
from the main query-processing loop. So for CALL statements it wouldn't
be invoked, and the procedure would be able to use its own explicit
Tom Lane [EMAIL PROTECTED] writes:
In fact it would more or less have to start in a transaction; keep in
mind that *we cannot do any database access* outside a transaction,
and therefore we could not have looked up the procedure in the system
catalogs in the first place without starting a
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
however commit that and let the procedure launch its own transactions
(compare to VACUUM, db-wide CLUSTER, etc) once we have read the
procedure body from the catalogs and done any pre-parsing we want to do.
Well I guess
On Thu, Sep 23, 2004 at 11:12:18AM -0700, Josh Berkus wrote:
A second point, which I brought up with you on IRC, is to eliminate
overloading and allow named parameter calls on SPs. This is extremely
useful functionality in T-SQL and PL/SQL; in fact, I'd say that it's
essential for any
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Tom Lane wrote:
How can clients distinguish multiple resultsets if they're using the
extended query protocol?
You'll get multiple repetitions of RowDescription/DataRows.
Ah, so the Execute spontaneously generates a RowDescription
Oliver Jowett [EMAIL PROTECTED] writes:
Here's a one-line patch that clarifies the Execute protocol docs slightly.
Applied.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL
On Fri, 2004-09-24 at 00:35, Tom Lane wrote:
I would be inclined to get rid of the separate NOPRINTADE code and make
NOFIXADE select both flags.
Barring any objections, I intend to apply the attached patch to HEAD
later today.
-Neil
Index: src/backend/main/main.c
I had previously mentioned that queries run much different depending on
whether a VACUUM ANALYZE is done or just a plain ANALYZE. At the time I
was told that that couldn't be and since I could just use the one that
worked better I didn't worry about it. Now I have updated my database
to 7.4 and
At 2004-09-20 02:16:50 -0400, [EMAIL PROTECTED] wrote:
Personally I find it annoying that you can't call describe on a
statement, only a portal, but that's the way it is now.
No, it isn't. Describe accepts both prepared statement and portal names.
In the former case, it returns
Marc Colosimo wrote:
Oops, I used the same setting as in the old hacking message (-O2, gcc
3.3). If I understand what you are saying, then it turns out yes, PG's
MemSet is faster for smaller blocksizes (see below, between 32 and
64). I just replaced the whole MemSet with memset and it is
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
2) switching the locale at run time is too expensive when using the system
library.
Fwiw I did some experiments with this and found it wasn't true.
Really?
We're
When I first log in to psql as a superuser, the first time I try to use
lo_export (), I get a reference leak warning. This does not happen on
subsequent attempts. However I can log out and log back in, and see the
error again the first time I execute the query.
Detail follows. Please CC
Hi!
I run pg_autovacuum:
./pg_autovacuum -D
but then I cannot find pg_autovacuum.log file.
Where shoud I look for it?
Thank you.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister
You also need to use -L to specify a location for the log file. By
default pg_autovacuum just logs to STDERR, so if you daemonize the
process (via -D), you won't be able to recover the output easily unless
you explicitly select a log file location.
-tfo
On Sep 22, 2004, at 2:29 AM, Iulia
This is a test mail
Casey Allen Shobe [EMAIL PROTECTED] writes:
When I first log in to psql as a superuser, the first time I try to use
lo_export (), I get a reference leak warning.
This is fixed post-beta2, I believe.
regards, tom lane
---(end of
53 matches
Mail list logo
