On Mon, 11 Oct 2004, Tom Lane wrote:
> 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 inp
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 inde
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 out
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 o
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
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: /var/lib/cvs/pgsql/src/Makefile.shlib,
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 addition, small
though
it be, at this stage of
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 fe
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
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 K&R style function definition
- make the type
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: /var/lib/cvs/pgsql/contrib/xml/p
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
"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;
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
On Sun, 2004-10-10 at 16:27, Sean Chittenden wrote:
> Is there any reason why the backend doesn't cast an unquoted integer to
> a boolean value?
Can you add some regression tests, please?
The patch treats any non-zero value as "true". Is that the behavior we
want, or should we only allow "1" as
On Sat, 2004-10-09 at 22:08, Neil Conway wrote:
> The attached patch makes the following cosmetic improvements [...]
Patch applied.
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscrib
What actually fails without this patch? I am curious why Cygwin needs
it and no one else does.
---
Reini Urban wrote:
> Attached hack fixes building under cygwin.
>
> The real analysis is in my "LDFLAGS overriding" thread,
Andrew Dunstan wrote:
>
> This also passes my modest testing, including the error case mentioned
> the other day, and appears to make sense. (I did notice a small case of
> non-postgres indentation, but I assume we'll have another run of
> pg_indent before the next beta?)
No, we typically do n
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.
> >>
> >>
> >
>
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 if
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
Bruce Momjian wrote:
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 g
This has been saved for the 8.1 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Sergej Sergeev wrote:
>
> >Sergej Sergeev <[EMAIL PROTECTED]> writes:
> >
> >
> >>>What happens if you feed other pseud
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
... 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 ac
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, there will always be one mor
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> ... 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
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
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 with
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 incons
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
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.
--
"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/automa
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
no
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 fro
>> 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 w
36 matches
Mail list logo
