Sean Chittenden wrote:
Alrighty. Do you want an updated patch for the single character
tweak or can you futz with it before committing? :)
I oppose casts from boolean to integer or vice versa.
Anyway, with Qt, it converts bool values to integers. I think Qt's
probably right on this front
Peter Eisentraut wrote:
Sean Chittenden wrote:
Alrighty. Do you want an updated patch for the single character
tweak or can you futz with it before committing? :)
I oppose casts from boolean to integer or vice versa.
Even _explicit_ casts only? It would not have any bad side effects on people
Michael Paesold [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
I oppose casts from boolean to integer or vice versa.
Even _explicit_ casts only? It would not have any bad side effects on people
not using it, would it?
I agree with Michael's position. I don't like implicit/automatic
I assume this is an 8.0 fix.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Bruce Momjian [EMAIL PROTECTED] writes:
I assume this is an 8.0 fix.
It looks more like a new feature to me ...
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Is there any reason why the backend doesn't cast an unquoted integer
to
a boolean value?
Hidden cross-category typecasts are evil. I'd accept this as an
explicit cast ('e' in pg_cast) but not automatic.
Also, what about the other direction? Providing a cast in only one
direction is pretty
pg_ctl(1)'s -w option works well if the default user can automatically
authenticate without any user intervention. The attached patch checks
the error message to see if it's asking for a password. The theory
being that if it's asking for a password, the backend is up. I'm not
entirely happy
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I assume this is an 8.0 fix.
It looks more like a new feature to me ...
They were requested features that we did not get done before freeze. It
would be great if we could
get them applied. We are continuing to
... it should have a SQLSTATE assigned, so you could
check for ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION ...
Ok, I've read over the code a little bit... it doesn't seem like
there's an obvious way to get the error code via libpq(3).
Hmmm ... I was thinking of PQresultErrorField, but you don't
Peter Eisentraut wrote:
Joshua D. Drake wrote:
We expected this to a degree of course, but if we can get some of
them in, it would be nice for the community
who wants to use plPerl.
On the other hand, it wouldn't be that nice for the community that
respects a good freeze. As you know,
Entirely expected (at least by me). I certainly respect a good freeze
(what a nice phrase).
However, there are outstanding patches from Abhijit Menon-Sen that are
genuine bug fixes that need to be queued, reviewed and applied.
It was worth a shot ;)
Joshua D. Drake
cheers
andrew
This patch aims to correct the issues with libpq.dll exporting too much
on win32. Contains the following changes:
* Exports PQgetssl() even if SSL support is not compiled in. In this
case, it always returns NULL. This is required so programs that expect
SSL version of the library does not crash
Andrew Dunstan wrote:
Considering that we're already a long time into the beta phase, and
we're still working out portability issues especially in the various
plug-ins, we really ought to be strict about the freeze in that area if
we ever want to get finished.
Agreed. This is
Neil Conway [EMAIL PROTECTED] writes:
The patch changes the system catalog; it probably ought to also bump the
catalog version number. That also means this probably isn't 8.0
material, unless we make an unrelated system catalog change in a future
beta (... and even then, I'm not sure if I'd
Magnus Hagander [EMAIL PROTECTED] writes:
*** src/interfaces/libpq/fe-secure.c28 Sep 2004 00:06:02 - 1.54
--- src/interfaces/libpq/fe-secure.c11 Oct 2004 19:50:22 -
***
*** 1201,1206
--- 1201,1212
return NULL;
return conn-ssl;
}
Dave Page wrote:
Hi,
I tried building a static libpq with Mingw, which it seems doesn't work
any more:
make[3]: *** No rule to make target `libpq.a', needed by
`all-static-lib'. Stop.
make[3]: Leaving directory `/cvs/pgsql/src/interfaces/libpq'
make[2]: *** [all] Error 2
make[2]:
This patch cleans up some unnecessary void * casts in contrib/xml and
contrib/xml2.
Barring any objections, I intend to apply this to HEAD tomorrow.
-Neil
Index: contrib/xml/pgxml_dom.c
===
RCS file:
This patch makes another set of small cosmetic improvements:
- remove another senseless extern keyword that was applied to a
function definition
- change a foo more function signatures from some_type foo() to
some_type foo(void)
- rewrite another KR style function definition
- make the type of
Is there any reason why the backend doesn't cast an unquoted integer
to
a boolean value?
Can you add some regression tests, please?
:-/ I have zero understanding or knowledge of the regression test
suite. Given the simplicity of the casts, does this really need a
require a regression test? I
Sean Chittenden [EMAIL PROTECTED] writes:
Can you add some regression tests, please?
Given the simplicity of the casts, does this really need a
require a regression test?
That request seems quite over-the-top to me too. The real problem here
is just whether we want to be accepting a feature
This patch fixes a build break for vpath builds, introduced by Bruce's
recent commit.
Barring any objections I intend to apply this in a few hours.
-Neil
Index: src/Makefile.shlib
===
RCS file:
On Mon, 11 Oct 2004, Sean Chittenden wrote:
The patch treats any non-zero value as true. Is that the behavior we
want, or should we only allow 1 as an integer representation of
true? (I'm not sure myself, I just don't think copying C here is
necessarily the best guide.)
I would posit
Stephan Szabo [EMAIL PROTECTED] writes:
On Mon, 11 Oct 2004, Sean Chittenden wrote:
I would posit that this is the desired behavior as it's consistent with
every language I can think of.
However, AFAIK it's inconsitent with the type input function which
supports '1' and '0' but not other
On Tue, 2004-10-12 at 11:54, Sean Chittenden wrote:
:-/ I have zero understanding or knowledge of the regression test
suite.
It is trivial: add some SQL to src/test/regress/sql/foo.sql, run the
tests, hand-verify the output (e.g. by looking at regression.diffs), and
then copy the updated
On Tue, 2004-10-12 at 12:37, Neil Conway wrote:
This patch fixes a build break for vpath builds, introduced by Bruce's
recent commit.
Applied to HEAD.
-Neil
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index
On Fri, 08 Oct 2004 00:26:06 -0400, Tom Lane [EMAIL PROTECTED] said:
Shinji Teragaito [EMAIL PROTECTED] writes:
152c152
SHLIB_LINK += `$(CC) -print-libgcc-file-name`
---
SHLIB_LINK += `$(CC) $(LDFLAGS) -print-libgcc-file-name`
Okay. I'm slightly worried about
26 matches
Mail list logo
