seems to be little syntax problem:
On Thu, 4 Sep 2003, Bruce Momjian wrote:
>
> Patch applied. Thanks.
>
> ---
>
>
> Andrew Dunstan wrote:
...
> >
> > !
> > ! To avoid this situation, run PostgreSQL
> > ! on a ma
Hi Bruce,
+
+/* getpwuid doesn't exist under win32 */
+#define getpwuid(uid) NULL
+
#endif /* pg_config_h_win32__ */
Why was this needed? I realize we don't have getpwuid() on Win32, but
we do have GetUserName() for cases where we need the name but not the
directory.
Because all the getpwui
Andrew Dunstan wrote:
Andreas,
You should check that the CIDR mask is a valid integer. You would need
to use strtol() rather than atoi() to do that. Perhaps this should be
hoisted out of ip.c:SockAddr_cidr_mask() and put in hba.c.
Right, I added this.
Regards,
Andreas
Index: hba.c
===
On Thu, Sep 04, 2003 at 01:06:15AM -0400, Bruce Momjian wrote:
> I have followed your suggestion and applied the following patch to have
> PGC_USERLIMIT track reset_val rather than session_val. I now see that
> all sources set the default, except SET:
I just updated my CVS workign directo
Hi Bruce.
As for mbvalidate, it seems that this is all right.
Thank you.
Regards,
Hiroshi Saito
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
>
> I went over this patch and fixed the problem with WIN32_CONSOLE. It
> seems you have a problem with mbvalidate. Is that c
Bruce,
can you the missing space on the marked line, or do you need another
patch from me?
thanks
andrew
Andriy Tkachuk wrote:
seems to be little syntax problem:
On Thu, 4 Sep 2003, Bruce Momjian wrote:
Patch applied. Thanks.
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> can you the missing space on the marked line, or do you need another
> patch from me?
Fixed.
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
Robert Treat writes:
> I didn't see it documented anywhere that a 0 in attypid of pg_attribute,
> and given the note on the need to match pg_type lest failure seems to
> warrant the mention.
A column is dropped if and only if attisdropped is true.
--
Peter Eisentraut [EMAIL PROTECTED]
-
Neil Conway writes:
> This patch makes a few minor improvements to the docs: make the
> conventions more consistent,
They are consistent: They're all lowercase. Until now.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4:
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> You should check that the CIDR mask is a valid integer. You would need
>> to use strtol() rather than atoi() to do that. Perhaps this should be
>> hoisted out of ip.c:SockAddr_cidr_mask() and put in hba.c.
> Right, I added thi
Bruce Momjian writes:
> How about this, that also suggests you mistyped the name:
>
> > HINT: Perhaps you need to use 'createlang' to load the language into
> > the database, or you mistyped the language name.
That's only one step away from this:
peter=# SELECT * FROM test;
ERROR: rela
Bruce Momjian writes:
> Huh? We have been uppercasing GUC variable names in most places
> already.
Currently, the documentation contains about 2 GUC variable names in upper
case, the rest is lower case. (The exception are the list headings in the
main description in runtime.sgml, which are all
Peter Eisentraut wrote:
> Neil Conway writes:
>
> > This patch makes a few minor improvements to the docs: make the
> > conventions more consistent,
>
> They are consistent: They're all lowercase. Until now.
Huh? We have been uppercasing GUC variable names in most places
already.
--
Bruce
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > How about this, that also suggests you mistyped the name:
> >
> > > HINT: Perhaps you need to use 'createlang' to load the language into
> > > the database, or you mistyped the language name.
>
> That's only one step away from this:
>
>
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Huh? We have been uppercasing GUC variable names in most places
> > already.
>
> Currently, the documentation contains about 2 GUC variable names in upper
> case, the rest is lower case. (The exception are the list headings in the
> main des
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Robert Treat writes:
>> I didn't see it documented anywhere that a 0 in attypid of pg_attribute,
>> and given the note on the need to match pg_type lest failure seems to
>> warrant the mention.
> A column is dropped if and only if attisdropped is true
Tom Lane wrote:
I thought this was still really messy, so I modified it to use a
separate "promote v4 address to v6" subroutine. I've applied the
attached patch (plus docs). It's not very well tested since I don't
have an IPv6 setup here; please check that it does what you want.
It SEGVs. Reason
On Friday 05 September 2003 16:24, Peter Eisentraut wrote:
> Robert Treat writes:
> > I didn't see it documented anywhere that a 0 in attypid of pg_attribute,
> > and given the note on the need to match pg_type lest failure seems to
> > warrant the mention.
>
> A column is dropped if and only if at
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I thought this was still really messy, so I modified it to use a
>> separate "promote v4 address to v6" subroutine. I've applied the
>> attached patch (plus docs). It's not very well tested since I don't
>> have an IPv6 setup here; pl
Tom Lane wrote:
IMHO the struct needs to be created officially by
getaddrinfo(), which will lead more or less the the same solution I
posted previously.
No, we just need to use datastructures that are under our control for
the values that will get passed to rangeSockAddr. A few more lin
Found some bugs with this patch - that makes it about 1 per line
patched... :-(
i) onerel->rd_nblocks should be elog'ed as an unsigned int.
ii) acquire_sample_rows has 2 return points - I had ignored the case
where the
onerel has < sample size tuples in it.
--- src/backend/commands/analyz
Andreas Pflug <[EMAIL PROTECTED]> writes:
> are you sure it's not just for beauty's sake?
What I didn't like about your last patch was the close coupling of the
CIDR/netmask processing to the v4-to-v6 conversion; as Andrew pointed
out, you were hacking into hba.c functionality that overlapped with
On Fri, 2003-09-05 at 17:16, Peter Eisentraut wrote:
> Currently, the documentation contains about 2 GUC variable names in upper
> case, the rest is lower case.
There are significantly more than 2 uses of upper-case GUC names in the
docs (more like 10 by my guess), but in any case, the current usa
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Neil Conway writes:
>> This patch makes a few minor improvements to the docs: make the
>> conventions more consistent,
> They are consistent: They're all lowercase. Until now.
The varnames listed in runtime.sgml are uppercase though, no? Or were
yo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> Huh? We have been uppercasing GUC variable names in most places
>> already.
> Currently, the documentation contains about 2 GUC variable names in upper
> case, the rest is lower case. (The exception are the list headings in
Tom Lane said:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
>> are you sure it's not just for beauty's sake?
>
> What I didn't like about your last patch was the close coupling of the
CIDR/netmask processing to the v4-to-v6 conversion; as Andrew pointed
out, you were hacking into hba.c functionalit
Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
> > are you sure it's not just for beauty's sake?
>
> What I didn't like about your last patch was the close coupling of the
> CIDR/netmask processing to the v4-to-v6 conversion; as Andrew pointed
> out, you were hacking into hba.c functi
Bruce Momjian said:
>
> Would you like me to conditionally add the IPv6 line to pg_hba.conf
> from initdb now?
>
As a matter of taste and possibly due to some paranoia I would prefer to
see it added unconditionally to pg_hba.conf and conditionally commented
out in initdb. (The paranoia is what say
[EMAIL PROTECTED] wrote:
> Bruce Momjian said:
> >
> > Would you like me to conditionally add the IPv6 line to pg_hba.conf
> > from initdb now?
> >
>
> As a matter of taste and possibly due to some paranoia I would prefer to
> see it added unconditionally to pg_hba.conf and conditionally commented
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Would you like me to conditionally add the IPv6 line to pg_hba.conf from
> initdb now?
I was going to tackle that tomorrow, but if you wanna do it, go for it.
regards, tom lane
---(end of broadcast)--
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Would you like me to conditionally add the IPv6 line to pg_hba.conf from
> > initdb now?
>
> I was going to tackle that tomorrow, but if you wanna do it, go for it.
No, go ahead. I wasn't sure if you were waiting for me so I asked.
31 matches
Mail list logo
