There is a way do do it on OS/2 but it requires that you run psql.exe in a
shell from the epm editor. That will allow you to feed input typed in the
editor to stdin of psql and the editor will capture stdout and stderr from
psql.
Setting it up is convoluted at best...
For people who want a simple
On Tue, 4 Jan 2005, Serguei A. Mokhov wrote:
On Tue, 4 Jan 2005, Peter Eisentraut wrote:
With the 8.0 release around the corner, this is as good a time as ever
to send in the last translation updates. If your files are not in CVS
right now, I don't have them, so please send them again in this case
In <[EMAIL PROTECTED]>, on 01/04/05
at 09:49 AM, Bruce Momjian said:
>Peter Eisentraut wrote:
>> [EMAIL PROTECTED] wrote:
>> > NOTE - the patch to the makefile is to keep it from constantly
>> > building psql.exe as the target "psql" all by itself is never created
>> > as the output executabl
(cc'ing -hackers)
Karel Zak wrote:
I think command status is common and nice feedback for client. I think
it's more simple change something in JDBC than change protocol that is
shared between more tools.
There is a bit of a queue of changes that would be nice to have but
require a protocol version
Attached is a makefile I hacked up to build pg_config under MSVC - the
reason is that it's required (more or less) in order to build the latest
DBD::Pg code and I was testing that out under MSVC. Should be saved as
src/bin/pg_config/win32.mak if we're to be consistent. I haven't yet
done a patc
On Wed, 2005-01-05 at 01:33 +1300, Oliver Jowett wrote:
> Karel Zak wrote:
> > I think each PG command returns some status. For example in libpq it's
> > possible check by PQcmdStatus(). I think JDBC can checks this status (by
> > own PQcmdStatus() implementation) and if PG returns string "CONNECTI
Todd Kover <[EMAIL PROTECTED]> writes:
>> Why is this necessary?
> It's largely useful in combination with restricting the interfaces
> listened to via the listen_addresses directive in the config file. As
> the code works now you can only connect via kerberos with a service
> principal derived f
On Tue, 4 Jan 2005, Peter Eisentraut wrote:
> With the 8.0 release around the corner, this is as good a time as ever
> to send in the last translation updates. If your files are not in CVS
> right now, I don't have them, so please send them again in this case.
A batch of Russian translation upda
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Tue, 4 Jan 2005, Peter Eisentraut wrote:
With the 8.0 release around the corner, this is as good a time as ever
to send in the last translation updates. If your files are not in CVS
right now, I don't have them, so please send them again in this
Peter Eisentraut wrote:
> [EMAIL PROTECTED] wrote:
> > NOTE - the patch to the makefile is to keep it from constantly
> > building psql.exe as the target "psql" all by itself is never created
> > as the output executable on OS/2 and Windows is psql.exe.
>
> If this were a problem on Windows, we'd
Hans-Jürgen Schönig wrote:
If the JDBC driver prefers different behaviour (maybe for prepared
statements) we should discuss further options for RESET.
Now there is: RESET CONNECTION (cleaning entire connection), RESET ALL
(cleaning GUCS only) and RESET some_guc.
Maybe we want RESET LISTENER, RESE
Karel Zak wrote:
I still don't see a big difference between DEALLOCATE and RESET -- both
can break the JDBC driver.
You have to go out of your way to break the driver via DEALLOCATE,
explicitly finding a statement name that the driver is using. There's
also a reasonably simple fix: make the proto
> Todd Kover <[EMAIL PROTECTED]> writes:
>
> > The attached patch adds a directive to the config file,
> > krb_server_hostname that allows the hostname that service tickets
> > are obtained against to be different from the hostname of the db
> > server.
>
> Why is this necessary?
It's larg
On Tue, 4 Jan 2005, [ISO-8859-1] Hans-Jürgen Schönig wrote:
> I completely agree with Karel. I think it is a bad idea to change the
> protocol for such a minor feature - i tend to call it overkill.
I agree. I don't think it's imperative to prevent or detect this
condition. The only real cal
I completely agree with Karel. I think it is a bad idea to change the
protocol for such a minor feature - i tend to call it overkill.
I want to add one point to this discussion: There is not just JDBC -
other connection pools or clients might want different behaviour (which
can from my point of
On Mon, 2005-01-03 at 19:14 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > Here's my bgwriter instrumentation patch, which gives info that could
> > allow the bgwriter settings to be tuned.
>
> Uh, what does this do exactly? Add additional logging output?
>
Produces output like this...
D
Bruce Momjian wrote:
Wow, yea, that is long. Not sure where that should go.
hmmm, yep - I could shorten it by removing :
- the COPY, ANALYZE (and maybe some of the INDEX) statements
- the queries and EXPLAINS at the end
However, this means that it is not clear what the point of the exercise
is
On Mon, 2005-01-03 at 20:27 -0500, Tom Lane wrote:
> I'm inclined to think that we'd have to add a protocol message that
> reports RESET CONNECTION to really answer objections of this type.
> That seems to bring the thing into the category of "stuff that forces
> a protocol version bump" :-(
>
>
18 matches
Mail list logo
