Maybe Vince could set up a Win32 porting project page, and since we now seem
to have a few interested parties willing to code on a native Win32 version,
they should have their own project page. This could make communication
easier for them and make sure the project doesn't die...
Chris
> -O
Neil Conway <[EMAIL PROTECTED]> writes:
> I'm seeing this with the current CVS code:
> [nconway:/home/nconway/pgsql]% initdb -D /data/pgsql/pgdata
> The files belonging to this database system will be owned by user "nconway".
> This user must also own the server process.
> /data/pgsql/bin/initdb:
Joe Conway <[EMAIL PROTECTED]> writes:
> Just noticed this a few minutes ago on build from cvs tip:
> make -C preproc all
> make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/preproc'
> bison -y -d preproc.y
> conflicts: 2 reduce/reduce
Yeah, the ECPG grammar has been broken for aw
I'm seeing this with the current CVS code:
[nconway:/home/nconway/pgsql]% initdb -D /data/pgsql/pgdata
The files belonging to this database system will be owned by user "nconway".
This user must also own the server process.
/data/pgsql/bin/initdb: test: =: unary operator expected
The database cl
Joerg Hessdoerfer <[EMAIL PROTECTED]> wrote:
[snip]
> The problem is not the fork() call itself, this has been done (MinGW
> and cygwin I know of, possibly others) but the speed of fork() on
> windows, it's creepingly slow (due to usermode copy, I assume ;-).
>
> IPC needs to be done, I'm j
Just noticed this a few minutes ago on build from cvs tip:
make -C preproc all
make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/preproc'
bison -y -d preproc.y
conflicts: 2 reduce/reduce
Joe
---(end of broadcast)---
TIP 4: Don't
I've attached a patch for libpgtcl which adds access to backend version
numbers.
This is via a new command:
pg_version ?? ??
Using readonly variables rather than a command was my first choice but I
decided that it was inappropiate for the library to start assigning global
variable(s) when t
On Thursday 16 May 2002 22:10, you wrote:
[...]
>
> What is the biggest problem here?
> The Shmem/IPC stuff, or the fork() stuff?
> I'm think that we could do a fork() implementation in usermode by copying
> the memory allocations. How fast that would be regarding the context
> switches, i don't k
Tom Lane <[EMAIL PROTECTED]> writes:
> Michael seems to feel that the tuple count should be nonzero if any
> of the replacement operations did anything at all. This does not
> make a lot of sense at the command tag level ("UPDATE 4" might not
> mean that 4 tuples were updated) but if you look at
> On Thu, 2002-05-16 at 13:47, Joerg Hessdoerfer wrote:
> > So, my route would be to get it to run *somehow* without paying
> > attention to speed and not to change much of the existing code,
> > THEN see how we could get rid of fork() on windows.
>
What is the biggest problem here?
The
Joel Burton wrote:
>
> > As per earlier vague hint, I'm bringing the CREATE FUNCTION syntax in line
> > with SQL99. Everything is fully backward compatible. Here is the new
> > synopsis:
> >
> > CREATE [OR REPLACE] FUNCTION name (args) RETURNS type
> > option [ option... ] [WITH (...)];
> >
>
On Tue, Apr 30, 2002 at 03:28:13PM -0400, Tom Lane wrote:
> Do you need to profile it? It seemed that the 32-bit behavior for
> many-equal-keys was so bad that it'd be easy to tell whether it's
> fixed, just by rough overall timing of a test case...
Sorry for taking yet again so long. Fitting
Hi All,
I can't see that there's any way to reset the stats collector without HUPing
the postmaster? Is there? Should there be?
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Eisentraut
> Sent: Thursday, May 16, 2002 1:22 PM
> To: PostgreSQL Development
> Subject: [HACKERS] Updated CREATE FUNCTION syntax
>
>
> As per earlier vague hint, I'm bringing the CREATE FUNCTION
Daniel writes:
> way to solve this is to use a translation method from
> principal to database users, i. e. a table.
> As the number of users of the database grows, using a
> preprocessed flat file to manage this becomes more and
> more of a problem. At that point one usually begins to
> look for
As per earlier vague hint, I'm bringing the CREATE FUNCTION syntax in line
with SQL99. Everything is fully backward compatible. Here is the new
synopsis:
CREATE [OR REPLACE] FUNCTION name (args) RETURNS type
option [ option... ] [WITH (...)];
where option is any of these in any order:
AS st
> > > Is there any existing way of making queries from
> > > postmaster (other than setting up a client
> > > connection from it)?
> >
> > There is no existing way, and none will be added in
> > the future either.
> > There are good system-reliability reasons for
> > keeping the postmaster
> > aw
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> Also somewhat NA centric is the two decimal places. This was originally
> meant to be locale driven but that is a problem for other reasons. What
> about defaulting it to two decimal places but allowing it to be redefined at
> table creation ti
On Thu, 2002-05-16 at 13:47, Joerg Hessdoerfer wrote:
> So, my route would be to get it to run *somehow* without paying attention to
> speed and not to change much of the existing code, THEN see how we could get
> rid of fork() on windows.
Getting it to compile and then "somehow" run on MinGW s
Actually, take a look at the thread starting at:
http://archives.postgresql.org/pgsql-hackers/2002-05/msg00665.php
Right now, IMHO, the big show stopper is passing global variables to the
child processes in Windows ... the above thread talks about a method of
pulling together the global
Hi all,
I followed the various threads regarding this for some time now. My current
situation is:
I'm working at a company which does industrial automation, and does it's own
custom products. We try to be cross-platform, but it's a windoze world, as
far as most measurement devices or PLCs are
On Thu, May 16, 2002 at 06:11:43AM -0400, D'Arcy J.M. Cain wrote:
> I know that the money type is supposed to be deprecated but I think that
Right.
> there is still some benefit to it. It is small and fast. There are some
> problems and I would like to address them.
>
> The output has a do
I know that the money type is supposed to be deprecated but I think that
there is still some benefit to it. It is small and fast. There are some
problems and I would like to address them.
The output has a dollar sign attached. This is NA centric and we said years
ago that we were going to d
On Wed, 2002-05-15 at 23:23, Dann Corbit wrote:
> The select(min) and select(max) took as long as the table scan to find
> the count. It seems logical if a btree type index is available (such
> as pk_cnx_ds_sis_bill_detl_tb) where the most significant bit of the
> index is the column requested, i
> The select(min) and select(max) took as long as the table scan to find
> the count. It seems logical if a btree type index is available (such
> as pk_cnx_ds_sis_bill_detl_tb) where the most significant bit of the
> index is the column requested, it should be little more than a seek
> first or
25 matches
Mail list logo
