Markus Schaaf wrote:
> src/interfaces/libpq/Makefile is missing a reference to libgssapi.
> The problem occurred while compiling 8.3.3 on NetBSD --with-gssapi,
> and is still present in HEAD. A patch is attached.
Applied and backpatched to 8.3.
Thanks!
//Magnus
--
Sent via pgsql-patches mailin
Hiroshi Saito wrote:
> Hi.
>
> I have problem of LC_TIME of windows.(CVS-HEAD)
>
> As for Version 8.3.3. It is edited by wrong gettext and is. (But, it is
> expressed.)
> http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/pg8.3.3-to_char_gettext_format.png
>
>
> As for Version 8.4. I
Jaime Casanova wrote:
> Hi,
>
> attached the patch i offer to make some internal SRF functions use
> output parameters.
Thanks!
Applied, along with the required catversion update.
//Magnus
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscript
Peter Eisentraut wrote:
> For some experiments I wanted to run the regression tests using a different
> database (possibly using pg_regress --dbname=), but the name "regression" is
> hardcoded in a few places. It's trivial to fix, see attached patch. Quick
> explanation: The fact that psql's \
Hiroshi Saito wrote:
> Hi.
>
> It seems that this is required in order to return the righter message.
> Please take into consideration. Thanks!
Thanks, applied.
//Magnus
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.post
Alex Hunsaker wrote:
> Tom Lane" <[EMAIL PROTECTED]> writes:
> > I am wondering if it's a good idea to hide the redundant entries
> > to reduce clutter in the pg_settings display. (We could do this
> > by adding a "hidden" boolean to struct config_enum_entry.)
> > Thoughts?
>
> The Attached patch
Magnus Hagander wrote:
> Alvaro Herrera wrote:
> > Andrew Chernow wrote:
> > > Tom Lane wrote:
> > >> Silently not locking is surely
> > >> not very safe.
> > >>
> > >
> > > Here is the dump code version of the patch. If anyo
Bruce Momjian wrote:
> Magnus Hagander wrote:
> > Bruce Momjian wrote:
> > > Bruce Momjian wrote:
> > > > Magnus Hagander wrote:
> > > > > Attached patch adds some error checking to the thread locking
> > > > > stuff in libpq. Previo
Andrew Chernow wrote:
> ! int
>pthread_mutex_init(pthread_mutex_t *mp, void *attr)
>{
> *mp = CreateMutex(0, 0, 0);
> + if (*mp == NULL)
> + return 1;
> + return 0;
>}
>
> Maybe it would be better to emulate what pthreads does. Instead of
> returing 1 to ind
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Magnus Hagander wrote:
> > > Attached patch adds some error checking to the thread locking
> > > stuff in libpq. Previously, if thread locking failed for some
> > > reason, we would just fall through and do thin
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Shouldn't we at least make it fail with EINVAL if "who" doesn't match
whichever semantics this code is able to implement?
Yeah, we only ever call it asking for our own process, but I guess
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Huh ... I'd forgotten about that ... although it seems to work only for
rather small values of "work", since the WIN32 code path isn't paying
attention to the "who" argument.
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I found another fairly big problem, which is that this stuff isn't even
going to begin to compile on Windows.
Where exactly is taht problem? In getrusage()? We have a getrusage() in
src/port that wo
Tom Lane wrote:
I wrote:
I'm starting to look through this now,
I found another fairly big problem, which is that this stuff isn't even
going to begin to compile on Windows.
Where exactly is taht problem? In getrusage()? We have a getrusage() in
src/port that works fine on Windows, no?
Alvaro Herrera wrote:
> Andrew Chernow wrote:
> > Tom Lane wrote:
> >> Silently not locking is surely
> >> not very safe.
> >>
> >
> > Here is the dump code version of the patch. If anyone wants the
> > return value idea, let me know.
>
> So is this a patch we want applied?
Please see my other t
Attached patch adds some error checking to the thread locking stuff in
libpq. Previously, if thread locking failed for some reason, we would
just fall through and do things without locking. This patch makes us
abort() instead. It's not the greatest thing probably, but our API
doesn't let us pass ba
Magnus Hagander wrote:
> Hiroshi Saito wrote:
> >> Anyway. If you get references to it, you need to pull in
> >> port/dirmod.c into psql as well. Normally, it would get this
> >> through libpgport, but it looks like your custom makfile is
> >> pulling t
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Peter Eisentraut wrote:
Btw., it is quite easily possible to use the autom4te tracing facility to
parse the configure.ac file, in case you are interested in generating some of
the Windows build code automatically.
Yeah, maybe. Let's
src\port\stat_pg_fixed.c
Thank you.
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 29, 2008 4:18 PM
To: Zubkovsky, Sergey
Cc: Tom Lane; Alvaro Herrera; Gregory Stark;
[EMAIL PROTECTED]; Magnus Hagander
Subject: Re: [HACKERS]
Hiroshi Saito wrote:
Anyway. If you get references to it, you need to pull in port/dirmod.c
into psql as well. Normally, it would get this through libpgport, but
it looks like your custom makfile is pulling the files in directly
instead. So adding dirmod to the list of stuff from src/port should
Hiroshi Saito wrote:
> Hi.
>
> Eh? It is strange...
> http://winpg.jp/~saito/pg_work/WIN32_BUILD_INF/psql_win32.mak
> Actually, it is required although psql is built. Have I missed
> something?
Note that building psql this way really isn't supported anymore :-)
Anyway. If you get references to i
The changes except the one to exports.txt look ok.
Why do you need to export pgwin32_safestat? It's *not* exported when
you build with mingw or the automated msvc build, and nothing breaks
there. Who is trying to use it?
//Magnus
Hiroshi Saito wrote:
> Hi.
>
> Oops, Certainly.
> I propose the m
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Hmm. I've preivously been told not to use "Failed to" but instead
> > use "Could not"... Didn't notice that Tom used the other one in his
> > suggestion.
>
> >
Albe Laurenz wrote:
> Tom Lane wrote:
> > I concur that the messages added to pg_ctl are bizarrely formatted.
> > Why would you put a newline in the middle of a sentence, when you
> > could equally well emit something like
> >
> > WARNING: online backup mode is active.
> > Shutdown will not comple
Alvaro Herrera wrote:
> Magnus Hagander wrote:
>
> > Applied with some minor changes to the error messages to make them
> > closer to our guidelines. (With my track record, it's not entirely
> > unlikely that someone will fix them further though :-P)
>
> I t
Albe Laurenz wrote:
> Magnus Hagander wrote:
> > This doesn't look like our normal coding standards, and should
> > probably be changed:
> > + if (0 != stat(BACKUP_LABEL_FILE, &stat_buf))
> >
> > (there's a number of similar places)
>
> I
Albe Laurenz wrote:
> Magnus Hagander wrote:
> > This doesn't look like our normal coding standards, and should
> > probably be changed:
> > + if (0 != stat(BACKUP_LABEL_FILE, &stat_buf))
> >
> > (there's a number of similar places)
>
> I
Albe Laurenz wrote:
> Simon Riggs wrote:
> > Patch applies, and works as described. Looks good for final apply.
> >
> > Few minor thoughts:
> >
> > * Text in pg_ctl should be WARNING, not Warning.
> > * CancelBackup() API looks strange, not sure why
> > * Need to mention that CancelBackup() is no
Bruce Momjian wrote:
> Magnus Hagander wrote:
> > Done that. Also, I needed to replace "gmake" with "make", since I'm
> > on linux...
> >
> > Anyway. It's been running for about 12 hours now, and I have
> > *nothing* in the outp
Andrew Chernow wrote:
> Tom Lane wrote:
> >Silently not locking is surely
> > not very safe.
> >
>
> Here is the dump code version of the patch. If anyone wants the
> return value idea, let me know.
Here's a version of this patch that doesn't use malloc - instead, I had
to change the callers to
Bruce Momjian wrote:
> bruce wrote:
> > Magnus Hagander wrote:
> > > Tom Lane wrote:
> > > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > > Attached is my test script. I ran it for 14 hours (asserts
> > > > > on), running 45
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Attached is my test script. I ran it for 14 hours (asserts on),
> > running 450 regression tests, with up to seven backends killed per
> > regression test.
>
> Hmm, there are something on the order of 1 SQL commands in our
> reg
Bryce Nesbitt wrote:
> Alvaro Herrera wrote:
> > People [are] complaining here that we don't teach people here
> > anyway, so hopefully my comments were still useful :-)
> >
> Yes they are useful. As a new patcher, where should I look for
> coding standards? How about a little FAQ at the
> top
Merlin Moncure wrote:
> On Fri, Apr 11, 2008 at 2:49 PM, Magnus Hagander
> <[EMAIL PROTECTED]> wrote:
> > Andrew Chernow wrote:
> > > I noticed several months ago, and came across it again today,
> > > that libpq's pthread-win32.c implementatio
Andrew Chernow wrote:
> Tom Lane wrote:
> > Andrew Chernow <[EMAIL PROTECTED]> writes:
> >> The attached patch replaces the win32 mutex calls with critical
> >> section calls. The change will not affect the behavior of the
> >> windows pthread_xxx functions.
> >
> > Why have you defined the lock/
Andrew Chernow wrote:
> Magnus Hagander wrote:
>
> >It changes the behavior when the pointer passed in is invalid from
> >crash to silent working, right?
>
> Correct, it a Habit. I sub-consciously write code that checks
> pointers. We can remove the pointer ch
Andrew Chernow wrote:
> I noticed several months ago, and came across it again today, that
> libpq's pthread-win32.c implementation is using CreateMutex rather
> than CRITICAL_SECTION. CreateMutex is like a semaphore in that it is
> designed to be accessible via name system-wide. Even when you
Magnus Hagander wrote:
> Magnus Hagander wrote:
> > Attached is a patch that attempts to fix the issues with stat() not
> > properly updating st_size on win32, as reported in this thread:
> > http://archives.postgresql.org/pgsql-hackers/2008-03/msg01181.php
> >
>
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > A whole lot simpler patch :-)
>
> Seems like you no longer need the !defined(_DIRMOD_C) bit here?
Correct. That wasn't the actual error, that was me misdiagnosing the
situation.
> Also please includ
Magnus Hagander wrote:
> Attached is a patch that attempts to fix the issues with stat() not
> properly updating st_size on win32, as reported in this thread:
> http://archives.postgresql.org/pgsql-hackers/2008-03/msg01181.php
>
> It has to have a chance to affect things
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Trying to prepare a patch that does it the normal way, but so far
> > I'm failing rather miserably. The *struct* stat is already
> > redefined on win32, so whenever I try #undef or so it conflicts
>
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Ick.
>
> > The reason not to do so was to avoid having to do the two filesystem
> > calls for *every* stat, instead just calling them both when we
> > actually need
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > + #ifndef WIN32
> > if (stat(xlogpath, &stat_buf) == 0)
> > + #else
> > + if (pgwin32_safestat(xlogpath, &stat_buf) == 0)
> > + #endif
>
> Ick. Please
Attached is a patch that attempts to fix the issues with stat() not
properly updating st_size on win32, as reported in this thread:
http://archives.postgresql.org/pgsql-hackers/2008-03/msg01181.php
It has to have a chance to affect things beyond just the
pg_relation_size() function, so this patch
Alvaro Herrera wrote:
> Magnus Hagander wrote:
> > Attached patch implements wal_sync_method as an enum. I'd like
> > someone to look it over before I apply it - I don't have the
> > machines to test all codepaths (and some of it is hard to test -
> > bette
Attached patch implements wal_sync_method as an enum. I'd like someone
to look it over before I apply it - I don't have the machines to test
all codepaths (and some of it is hard to test - better to read it and
make sure it's right).
In order to implement the enum guc, I had to break out a new
SYN
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > One question: should \df really list *all* nonsystem functions? Or
> > just the ones that are visible in your search path? I'd be
> > inclined to say the second.
> >
> >
> >
>
>
> +1 (although maybe that discussion belongs on -hackers, or eve
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > If we're implementing IF NOT EXISTS across the board, let's do that
> > for languages at the same time as for others.
>
> Yeah, if we were going to do it at all it should be handled
> acro
Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> >> The way we've solved this problem for other CREATE commands is to
> >> add "OR REPLACE" option, instead of "IF NOT EXISTS". We should do
> >> the same here.
> >
> > If we're willing to consider a so
On Wed, 26 Mar 2008 11:35:22 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> >>> The \password command appears to be documented in the psql
> >>> reference page, but not included in the output of the \? command.
&g
On Wed, 26 Mar 2008 10:44:43 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > The \password command appears to be documented in the psql reference
> > page, but not included in the output of the \? command. Is there any
>
On Wed, 26 Mar 2008 10:43:48 -0300
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Heikki Linnakangas wrote:
> > Magnus Hagander wrote:
> >> + fprintf(output, _(" \\password [USERNAME]\n"
> >> + " securely
>
The \password command appears to be documented in the psql reference
page, but not included in the output of the \? command. Is there any
actual reason for that, or should I just apply the attached patch?
(which means I will apply it unless there are objections :-P)
//Magnus
Index: src/bin/psql/h
I haven't had time to look through the patch, but reading Gregs comments
I noted:
2) The genbki.sh change could be a bit tricky for multi-platform builds (ie
OSX). I don't really see an alternative so it's just something to note for
the folks setting that up (Hi Dave).
Changes to genbk
On Wed, Mar 05, 2008 at 07:38:21PM -0300, Alvaro Herrera wrote:
> Magnus Hagander wrote:
> > Alvaro Herrera wrote:
>
> >> I checked the Majordomo logs and there's nothing about those patches.
> >> I do see one message with the "Subject: pgsql: Clean up d
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Weird, I haven't seen the commit message come through here.
Yeah, that's strange -- the (2) commit message got to me, but this one
hasn't.
None of the back-patch
commits
On Wed, Mar 05, 2008 at 08:18:19AM -0500, Tom Lane wrote:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> What I'd suggest is declaring the actual variable as int. You can still
> >> use an enum typedef to declare the values, and just avert your eyes
> >> when you have
On Tue, Mar 04, 2008 at 09:35:27PM +, Heikki Linnakangas wrote:
>
> We could keep using the assignment hooks. But they could be a lot
> simpler than they are nowadays, if the string -> int conversion was done
> by the GUC machinery:
>
> static const char *
> assign_client_min_messages(int n
On Tue, Mar 04, 2008 at 03:28:30PM +, Dave Page wrote:
> On Fri, Feb 29, 2008 at 6:41 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > Will you provide a patch for that, or should I? (I remind you I have no
> > box ready to reproduce it on, so it helps a lot
Attached is my first work at implementing GUC enums. It's not done yet,
obviously, but I did hit a problem that I need to ask about. So I'll just
send what I have now for comments.
The patch only converts a couple of the potential enum variables to the new
type, mainly as a proof of concept. But a
Dave Page wrote:
On Fri, Feb 29, 2008 at 3:25 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
I noticed that as well when looking at the code, but since I ran my tests
on non-vista platforms I didn't hit the actual problem.
Dave - it shuold be a simple case of adding the same line
On Fri, Feb 29, 2008 at 12:17:51AM -0500, Andrew Dunstan wrote:
>
>
> Dave Page wrote:
> >The attached patch fixes problems reported primarily on Vista, but
> >also on some Windows 2003 and XP installations in which initdb reports
> >that it cannot find postgres.exe.
> >
> >This occurs because of
On Thu, Feb 21, 2008 at 03:02:07PM +, Dave Page wrote:
> The attached patch fixes problems reported primarily on Vista, but
> also on some Windows 2003 and XP installations in which initdb reports
> that it cannot find postgres.exe.
>
> This occurs because of security-related changes implement
On Tue, Feb 19, 2008 at 06:46:24PM +0300, Teodor Sigaev wrote:
> Magnus, could you provide dump of tsvector column of archive search?
> I'll make a test with and without Tom's patch.
>
> >>>I have not done any performance testing of these changes --- does
> >>>anyone have specific test scenarios t
On Tue, Feb 19, 2008 at 11:25:14AM +0100, Gevik Babakhani wrote:
> this is a fix for the compiler warnings on MSVC due differences in
> declaration and implementation of _yconv in strfime.c.
>
> I have testing this patch on:
>
> - MSVC 8
> - gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
Argh for
On Mon, Feb 18, 2008 at 04:32:58PM +0100, Bjorn Munch wrote:
> On 13/02 10.51, Heikki Linnakangas wrote:
> > Heikki Linnakangas wrote:
> > >I'll add some tests to cover timestamps > 2038.
> >
> > Attached is a new patch, with a couple of new regression tests. No other
> > changes.
>
> Ouch! Thi
Gevik Babakhani wrote:
Haven't looked into the details of the patch yet, will do so.
But the first thing I notice - you say this is only for MSVC,
right? But the patch will also change the behaviour for the
mingw build. Since you say you haven't tested on it, does the
documentation imply that
Gevik Babakhani wrote:
Hereby a patch that fixes NLS support on PG 8.3 compiled with MSVC.
Haven't looked into the details of the patch yet, will do so. But the
first thing I notice - you say this is only for MSVC, right? But the
patch will also change the behaviour for the mingw build. Since
On Fri, Feb 08, 2008 at 09:29:31PM +0900, Hiroshi Saito wrote:
> Hi Magnus.
>
> I received the problem of 8.0.15 from the user in Japan, and we understood
> that there was a patch forgotten
>
> per report KAZUYA-ozawa.(this is shift-jis)
> http://winpg.jp/~saito/pg80/error.txt
>
> Of course
On Thu, Jan 17, 2008 at 04:14:59PM +0900, Hiroshi Saito wrote:
> Hi.
Hi. Sorry about the delay in the response.
> First:
> I needed other programs, in order to test what always built independent
> libpq.dll.
> Therefore, environment was considered variously. Then, I thought that a
> sample pro
On Fri, Jan 18, 2008 at 12:35:40PM +0100, Peter Eisentraut wrote:
> Am Freitag, 18. Januar 2008 schrieb Magnus Hagander:
> > Not that much more than moving the socket file to a secure directory. Both
> > rely on configuring the client properly. It's arguably a lot easier
On Fri, Jan 18, 2008 at 11:24:09AM +0100, Peter Eisentraut wrote:
> Am Donnerstag, 17. Januar 2008 schrieb Andrew Dunstan:
> > I agree. I remain of the opinion that this is not a problem than can be
> > solved purely within the bounds of postgres.
>
> Well, the SSL patch I showed certainly solves
On Thu, Jan 17, 2008 at 12:02:06PM +0200, Marko Kreen wrote:
> - s/2440/4880/
> - mention all built-in hashes
> - s/pgcrypto/PostgreSQL/ in one place
> - no need to mention 2440bis anymore
>
> Explanation - pgp code was written from the start to conform with
> rfc2440bis (now rfc4880), so any ment
On Fri, Jan 11, 2008 at 12:29:53AM +0900, Hiroshi Saito wrote:
> From: "Magnus Hagander" <[EMAIL PROTECTED]>
>
> >>I don't think of a good idea. However, since our document has announced
> >>officially, saying >=VC7.1. Therefore, I think that it
On Fri, Jan 11, 2008 at 12:15:53AM +0900, Hiroshi Saito wrote:
> From: "Magnus Hagander" <[EMAIL PROTECTED]>
>
> >>Condition understanding of '>=' is not made as for namke of VC6 to a
> >>regrettable thing, but it causes an error to i
On Thu, Jan 10, 2008 at 11:52:15PM +0900, Hiroshi Saito wrote:
> Hi.
>
> - Original Message -
> From: "Magnus Hagander" <[EMAIL PROTECTED]>
>
>
> >On Wed, Jan 09, 2008 at 04:01:20PM +0900, Hiroshi Saito wrote:
> >>Hi Magnus, and Dave
On Wed, Jan 09, 2008 at 04:01:20PM +0900, Hiroshi Saito wrote:
> Hi Magnus, and Dave.
>
> It seems that it is different in nmake although the initial value of
> VisualStudio is embedding. Then, It sees a reference problem by
> the dll independent. Therefore, embedding considers like an ideal.
>
On Wed, Jan 09, 2008 at 02:40:42PM +0900, Hiroshi Saito wrote:
> Hi Magnus.
>
> From: "Magnus Hagander" <[EMAIL PROTECTED]>
>
>
> >I see the problem now. In my dev kit, there is no error for using
> >_USE_32BIT_TIME_T on Win64. That's why I got
On Thu, Dec 20, 2007 at 10:02:24AM +0900, Hiroshi Saito wrote:
> Hi.
>
> - Original Message -
> From: "Magnus Hagander" <[EMAIL PROTECTED]>
>
>
> >On Wed, Dec 19, 2007 at 11:19:54AM +0900, Hiroshi Saito wrote:
> >>Ummm, Sorry...former pa
On Tue, Dec 18, 2007 at 12:41:56PM +0530, Dhanaraj M wrote:
> Hi all,
>
> This is the continuation to the discussion that we had in the hacker's
> list.
> http://archives.postgresql.org/pgsql-hackers/2007-08/msg00684.php
>
>
> Here, I like to add some details in 20.2.6. PAM authentication secti
On Fri, Dec 14, 2007 at 10:47:02AM -0500, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
> >On Fri, Dec 14, 2007 at 03:39:14PM +, Dave Page wrote:
> >
> >>Andrew Dunstan wrote:
> >>
> >>>Writing and calling a temp .bat file might b
On Wed, Dec 19, 2007 at 11:19:54AM +0900, Hiroshi Saito wrote:
> Ummm, Sorry...former patch to be disregarded.
> Although 64bit mak is experimental, it needs to be compiled.
> Please apply this.
Is this really correct? Fromw hat I can tell you *both* tell us not to
check the value *and* set the
On Fri, Dec 14, 2007 at 03:39:14PM +, Dave Page wrote:
> Andrew Dunstan wrote:
> > Writing and calling a temp .bat file might be yucky - having to keep two
> > environment files is a lot more yucky, IMNSHO, and we shouldn't make
> > people do it.
>
> +1
Ok, I guess I'm outvoted ;-) I don't ca
On Mon, Dec 10, 2007 at 09:56:39AM +, Dave Page wrote:
> Dave Page wrote:
> > Tom Lane wrote:
> >> Dave Page <[EMAIL PROTECTED]> writes:
> >>> Gregory Stark wrote:
> An alternative is leaving it in the project file but putting
> something like
> this in c.h:
> >>
> >> Put it in w
On Mon, Dec 10, 2007 at 10:47:19PM -0500, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Stephen Frost wrote:
> >> I'm going to have to vote 'silly' on this one.
>
> > It's a matter of being consistent. If we think such a facility shouldn't
> > be provided on security grounds, t
On Sun, Dec 09, 2007 at 02:40:37PM -0500, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
> >>
> >>You seem to have misunderstood what I am suggesting. Of course we should
> >>document use of buildenv.pl in addition to the hacky fix to the .bat
> >
On Mon, Dec 03, 2007 at 04:31:42PM +0100, Hannes Eder wrote:
> Tom Lane wrote:
> >Removed Files:
> >-
> >pgsql/contrib/spi:
> >README.spi
> >
> > (http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/spi/README.spi)
> >
>
> Don't try to install a missing file
On Tue, 2007-11-06 at 18:10 -0800, Henry B. Hotz wrote:
> On Nov 6, 2007, at 6:27 AM, Magnus Hagander wrote:
> > On Fri, Nov 02, 2007 at 11:23:30AM -0700, Henry B. Hotz wrote:
> >>>>>> I'm not entirely sure what the intended semantics of
> >>>>>
A thought on this - should it not go in contrib/tsearch2 replacing the old
deprecated stuff, instead of creating yet aother contrib dir?
/Magnus
> --- Original Message ---
> From: Bruce Momjian <[EMAIL PROTECTED]>
> To: Pavel Stehule <[EMAIL PROTECTED]>
> Sent: 07-11-09, 01:35:49
> Subj
On Fri, Nov 02, 2007 at 11:23:30AM -0700, Henry B. Hotz wrote:
> I'm not entirely sure what the intended semantics of
> krb_match_realm
> are, but if you're trying to match the GSSAPI-authenticated name
> against
> "value_of(PGUSER)@value_of(krb_match_realm)" then you need t
Henry B. Hotz wrote:
>
> On Nov 1, 2007, at 6:33 AM, Tom Lane wrote:
>
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> Tom Lane wrote:
>>>> Also the elog message texts need a bit of copy-editing.
>>
>>> Probably ;-) Got any specific hin
Henry B. Hotz wrote:
>
> On Nov 1, 2007, at 1:40 PM, Magnus Hagander wrote:
>
>> Henry B. Hotz wrote:
>>> Thank you very much. This helps, but I'm still evaluating how much.
>>>
>>> I *can* point at one problem though: you do a strchr(gbuf.valu
Henry B. Hotz wrote:
> Thank you very much. This helps, but I'm still evaluating how much.
>
> I *can* point at one problem though: you do a strchr(gbuf.value, '@')
> and then error out if there isn't a Kerberos realm there. In fact that
> is exactly the default username of at least one of the
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Also the elog message texts need a bit of copy-editing.
>
>> Probably ;-) Got any specific hints, so I don't have to go through the
>> iteration twice?
>
> The
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Attached patch implements krb_match_realm for krb5, gssapi and sspi per
>> complaint from Henry. Comments welcome.
>
> Minor gripe: "krb_match_realm" sounds like it should be a boolean:
>
Attached patch implements krb_match_realm for krb5, gssapi and sspi per
complaint from Henry. Comments welcome.
Working on documentation which will of course be ready when it's
committed :)
Oh, and it changes the krb username handling to be the same as the
gssapi one. I've never heard of anybody
Heikki Linnakangas wrote:
> Magnus Hagander wrote:
>> So I was fixing my MingW environment to test and fix that issue with the
>> functions missing. In doing so, I came across the error previously
>> discussed that gettimeofday() is now suddently defined in the latest
>
So I was fixing my MingW environment to test and fix that issue with the
functions missing. In doing so, I came across the error previously
discussed that gettimeofday() is now suddently defined in the latest
versions of mingw, but wasn't before.
So I figured I'd have to fix that. Attached is a p
Dave Page wrote:
> Tom Lane wrote:
>> [ looks again... ] Actually, I think you just proved my point for me.
>> The ZeroMemory call should go away, no?
>
> Yup, quite correct. v3 attached.
Great job tracking this down!
Patch looks good from here (after the fixes per Tom).
Applied, many thanks!
Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> So don't initialize a local variable unless
>>> you're giving it an actually meaningful value.
>
>> The downside is that we see a useless warning that, if sufficiently
>> multiplied, might make it hard to see something
1 - 100 of 685 matches
Mail list logo
