Try to reduce confusion about what is a lock method identifier, a lock
method control structure, or a table of control structures.
. Use type LOCKMASK where an int is not a counter.
. Get rid of INVALID_TABLEID, use INVALID_LOCKMETHOD instead.
. Use INVALID_LOCKMETHOD instead of (LOCKMETHOD) NUL
Bruce Momjian writes:
> Oh. Any ideas on how to handle that? The other reference uses:
>
> override CPPFLAGS+="-I$(top_srcdir)/src/include/port/win32"
>
> but top_srcdir isn't defined at this point.
If you put this in the port makefile, then it should work.
> This is there only so 'confi
Bruce Momjian writes:
In mbprint.c:
+ #ifndef PGSCRIPTS
+ #include "settings.h"
+ #endif
Why is this needed, considering that the rest of the code was not changed
to make use of any setting? The print modules in psql should not make use
of psql-specific settings. That's why there are extensive
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Why does configure need to see those files? Surely you don't need
> configure to test the capabilities of our own source tree?
Looking at the contents of src/include/port/win32, I would imagine the
problem is configure will decide we don't HAVE_SYS_S
Manfred Koizar <[EMAIL PROTECTED]> writes:
> [large patch]
Looks reasonable except
> +#define BITS_OFF(i) ~(1 << (i))
I'd put another pair of parens around that. Also, it might be worth
moving into a header file. There is at least one place in proc.c that
manipulates lock masks using explicit
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Oh. Any ideas on how to handle that? The other reference uses:
> >
> > override CPPFLAGS+="-I$(top_srcdir)/src/include/port/win32"
> >
> > but top_srcdir isn't defined at this point.
>
> If you put this in the port makefile, then it shou
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> In mbprint.c:
>
> + #ifndef PGSCRIPTS
> + #include "settings.h"
> + #endif
>
> Why is this needed, considering that the rest of the code was not changed
> to make use of any setting? The print modules in psql should not make use
> of psql-spec
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Why does configure need to see those files? Surely you don't need
> > configure to test the capabilities of our own source tree?
>
> Looking at the contents of src/include/port/win32, I would imagine the
> problem is configure wil
Bruce Momjian writes:
> The problem is that mbvalidate() has this code:
>
> if (GetVariableBool(pset.vars, "WIN32_CONSOLE"))
> CharToOem(pwcs, pwcs);
>
> That's why I needed the #ifdef so it only tests from psql. This code
> was just broken without that test, and because no on
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > The problem is that mbvalidate() has this code:
> >
> > if (GetVariableBool(pset.vars, "WIN32_CONSOLE"))
> > CharToOem(pwcs, pwcs);
> >
> > That's why I needed the #ifdef so it only tests from psql. This code
> > was just b
Bruce Momjian writes:
> Is this a valid feature? Should I document it?
Maybe it's a valid feature, but the implementation is not valid.
Other applications also make use of the print routines (e.g., createlang),
and they cannot interactively set variables. So I repeat: the print
routines may not
Bruce Momjian writes:
> As Tom mentioned, it doesn't find things like sys/socket.h, which we
> have added to src/include/port/win32/. This was done to elimintate
> #ifdef of the include files that are Win32-specific.
OK, then you can reference the top source directory as $srcdir in
configure.
-
Peter Eisentraut wrote:
> c) Problem: 8bit characters were displayed/interpreted wrong in psql
>This is due to the fact that the Win32 "console" uses a
>different encoding than the rest of the Windows system
> Solution: Introduced a new psql variable WIN32_C
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > As Tom mentioned, it doesn't find things like sys/socket.h, which we
> > have added to src/include/port/win32/. This was done to elimintate
> > #ifdef of the include files that are Win32-specific.
>
> OK, then you can reference the top source
On Sun, 07 Sep 2003 10:19:07 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>> +#define BITS_OFF(i) ~(1 << (i))
>
>I'd put another pair of parens around that. Also, it might be worth
>moving into a header file. There is at least one place in proc.c that
>manipulates lock masks using explicit shifts,
A test for null string is missing here:
*** pgsql/src/backend/utils/mmgr/mcxt.c 2003-09-02 13:30:05.0 +0200
--- pgsql.old/src/backend/utils/mmgr/mcxt.c 2003-08-04 04:40:08.0
+0200
*** char *
*** 620,632
MemoryContextStrdup(MemoryContext context, const char *strin
Bruce Momjian wrote:
I think we ought to detect the console type automatically anyway.
Certainly we don't want people to have to set this variables all the time.
Agreed. Automatic is ideal. Any ideas out there?
Does input from the console work correctly right now?
What about setting th
Larry Rosenman wrote:
Here's a quickie patch I did to fix it.
Patching this or not, if the function's called the backend will SEGV
either (at least on my 2.4.20 it does) because a IPV6 address is copied
in the memory space of a IPV4 address.
Regards,
Andreas
---(end o
"Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> A test for null string is missing here:
> MemoryContextStrdup(MemoryContext context, const char *string)
> {
> char *nstr;
> -
> - if ( !string )
> - {
> - elog(ERROR, "MemoryContextStrdup called with a NULL pointer");
> - return NULL;
> - }
This se
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Larry Rosenman wrote:
>> Here's a quickie patch I did to fix it.
> Patching this or not, if the function's called the backend will SEGV
> either (at least on my 2.4.20 it does) because a IPV6 address is copied
> in the memory space of a IPV4 address.
Manfred Koizar <[EMAIL PROTECTED]> writes:
>> I'd put another pair of parens around that. [etc]
> Done. Small patch attached, should be applied after the large patch.
> Big fat all-in-one patch available on request.
Looks good to me. Bruce, please add to pending queue for 7.5?
Tom Lane wrote:
> Manfred Koizar <[EMAIL PROTECTED]> writes:
> >> I'd put another pair of parens around that. [etc]
>
> > Done. Small patch attached, should be applied after the large patch.
> > Big fat all-in-one patch available on request.
>
> Looks good to me. Bruce, please add to pending qu
This has been saved for the 7.5 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Manfred Koizar wrote:
> On Sun, 07 Sep 2003 10:19:07 -0400, Tom Lane <[EMAIL PROTECTED]>
> wrote:
> >> +#define BITS_OFF(i
Short summary:
This patch allows ISO 8601 "time intervals" using the "format
with time-unit designators" to specify postgresql "intervals".
Below I have (A) What these time intervals are, (B) What I
modified to support them, (C) Issues with intervals I want
to bring up, and (D) a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> This has been saved for the 7.5 release:
> http:/momjian.postgresql.org/cgi-bin/pgpatches2
BTW, that page still calls itself "PostgreSQL Items For 7.4."
regards, tom lane
---(end of broadcast)--
"Ron Mayer" <[EMAIL PROTECTED]> writes:
>Compared to the ISO 8601 time interval specification, the
>postgresql interval syntax is quite verbose. For example:
> Postgresql interval: ISO8601 Interval
> ---
> '1 year
Is there a way of producing as well as reading this format? Or did I miss
something?
cheers
andrew
Ron Mayer said:
> Short summary:
>
> This patch allows ISO 8601 "time intervals" using the "format
> with time-unit designators" to specify postgresql "intervals".
>
> Below I have (A) What
Manfred Koizar wrote:
> On Sun, 7 Sep 2003 11:43:42 -0400 (EDT), Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
> >I assume this completes this TODO:
> >
> > * Order duplicate index entries by tid for faster heap lookups
>
> I don't think so, because the patch does nothing to keep the sort
> order
On Sun, 07 Sep 2003 12:23:28 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>Maybe so, but it would degrade the performance in the unique-index case
>if we do it as the TODO is worded.
The patch would only hurt with a unique index, if there are lots of
duplicate tuples at CREATE INDEX time.
>My own o
On Mon, 01 Sep 2003 08:46:09 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>[EMAIL PROTECTED] writes:
>> it took 69 minutes to finish, 75% of this time was devoted to create 2
>> indexes on varchar(2) with value being 'O', 'N' or null;
>
>I still say it's either strcoll or qsort's fault.
If qsort is
I assume this completes this TODO:
* Order duplicate index entries by tid for faster heap lookups
and you will submit it for 7.5? If you want to post it now, I can get
it into the 7.5 queue so we don't forget it.
-
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I assume this completes this TODO:
> * Order duplicate index entries by tid for faster heap lookups
I don't know why that TODO entry exists, but I think the idea is
counterproductive. The existing btree code will tend to put newer
versions of a ro
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I assume this completes this TODO:
> > * Order duplicate index entries by tid for faster heap lookups
>
> I don't know why that TODO entry exists, but I think the idea is
> counterproductive. The existing btree code will tend to
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> * Order duplicate index entries by tid for faster heap lookups
>
>> I don't know why that TODO entry exists, but I think the idea is
>> counterproductive.
> I assume you are talking about a unique index that probably only has a
> few
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >>> * Order duplicate index entries by tid for faster heap lookups
> >
> >> I don't know why that TODO entry exists, but I think the idea is
> >> counterproductive.
>
> > I assume you are talking about a unique index
On Sun, 7 Sep 2003 11:43:42 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>I assume this completes this TODO:
>
> * Order duplicate index entries by tid for faster heap lookups
I don't think so, because the patch does nothing to keep the sort
order once the index is initially created
--On Sunday, September 07, 2003 14:19:00 -0500 Larry Rosenman
<[EMAIL PROTECTED]> wrote:
--On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote:
[snip]
/usr/local/bin/gmake -C libpq all
gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/libpq'
cc -O -Kinline,no_h
37 matches
Mail list logo
