Hi,
Win32 threads support are both going to be a lot of work and maybe
we'll need in the future one or both - is there any chance Postgres
developers look at the Apache experience? Briefly, Apache 2 had the some
problems as are discussed here (need to support Win, problems with Win32
fork,
On Fri, 2002-05-10 at 06:27, Tom Lane wrote:
I'm also concerned about having an understandable definition for the
OID returned for an INSERT query --- if there are additional INSERTs
triggered by rules, does that mean you don't get to see the OID assigned
to the single row you tried to
1) Cygwin latest CVS installer version supports command lines.
2) Cygwin setup.exe is not needed. According to Robert Collins, an appropriate
setup.ini file can be used for automatic installation.
Cheers,
Jean-Michel POURE
---(end of
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
I have a little patch that actually allows SPI_prepare() to
use UNKNOWN_OID in the passed in parameter type array and
put's the choosen datatypes Oid back into there.
The parser treats those parameters like
Hiroshi Inoue wrote:
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Of cource it is nice to have a complete solution
immediately but it doesn't seem easy. My patch is
only a makeshift solution but fixes the most
siginificant case(typical updatable views).
I would
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Of cource it is nice to have a complete solution
immediately but it doesn't seem easy. My patch is
only a makeshift solution but fixes the most
siginificant case(typical updatable views).
I would like to devise a complete solution
Hi,
if it is acceptable for subtransactions to use up transaction numbers,
then here is a half baked RFC for a possible implementation.
If not, forget the rest of this message.
The proposed implementation works much like the current transaction
handling. It needs an additional system table
Robert wrote:
Hi,
Win32 threads support are both going to be a lot of work and maybe
we'll need in the future one or both - is there any chance Postgres
developers look at the Apache experience? Briefly, Apache 2 had the some
problems as are discussed here (need to support Win,
Le Vendredi 10 Mai 2002 13:13, mlw a écrit :
I am starting to come to the conclusion that the PostgreSQL group is
satisfied with cygwin, and the will to create a native Win32 version does
not exist outside of a few organizations that are paying developers to
create one.
The more important is
Jean-Michel POURE wrote:
Without some buy-in from the core team, I'm not sure I am willing to spend
my time on it. If someone would be willing to fund the 100 or so man-hours
required to do it, then that would be a different story.
I suggest we focuss on providing a minimal PostgreSQL +
Le Vendredi 10 Mai 2002 14:06, mlw a écrit :
Sorry, I'm not interested in a cygwin version of PostgreSQL. I think it
will do more harm than good. If we make it something that people want to
try, and then they TRY it, they will find that is sucks, then we lose. It
is very hard to remove the
On Thu, May 09, 2002 at 06:33:58PM +0100, Nigel J. Andrews wrote:
On Thu, 9 May 2002, Thomas Lockhart wrote:
gborg is another way to organize, and of course www.pgaccess.org is a
way too. It partly depends on how you see the future of pgaccess. If it
stays tightly coupled to pgsql, then
On Thu, May 09, 2002 at 10:24:00PM +0200, Iavor Raytchev wrote:
nice summary of how we got here
PROPOSAL
What pgaccess needs is some fresh air - it needs a small and fresh team. It
needs own web site, own cvs, own mailing list. So that the people who love
it, write for it and really need
Hi everybody,
I think, that our job is to help this project to grow up to fit the
needs of the people that are using it. In the last months I didn't
notice any activity around it. And there are real expectations that are
still unsatisfied.
This project really needs the fresh air. I think, to
Hello everybody,
After Marc Fournier commented, it is time for pgaccess.org to make a
decision.
It is clear the project needs the following tools.
- web site
- mailing list(s)
- cvs
- bug tracking system
It is clear, that there is a small new group with fresh desire to contribute
in a
Dear all,
Here is a copy of a mail received from
Robert Collins [EMAIL PROTECTED].
Jean-Michel POURE
-Original Message-
From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 10, 2002 6:30 PM
Does setup.exe support uninstalling just like rpm -e package
name does?
Jean-Michel POURE wrote:
Le Vendredi 10 Mai 2002 14:06, mlw a écrit :
Sorry, I'm not interested in a cygwin version of PostgreSQL. I think it
will do more harm than good. If we make it something that people want to
try, and then they TRY it, they will find that is sucks, then we lose. It
Hi everyone,
Jean-Michel POURE wrote:
snip
- second move : release a bundle of pgAdmin2 + PostgreSQL on
http://www.postgresql.org, Bloodshed and other sites.
Don't know if it's useful to know, but a PostgreSQL project got setup on
Sourceforge recently (no CVS), pretty much just so
Dear Mark,
Agreed except for paths (see below). But now that we agree, why not move to
Windows in three steps:
1) Release a minimal Cygwin + PostgreSQL installer,
2) Have 100.000 downloads or more Windows developpers,
3) Work as a team on a Windows port.
By the way : Cygwin accepts both
Jean-Michel POURE wrote:
Dear Mark,
Agreed except for paths (see below). But now that we agree, why not move to
Windows in three steps:
1) Release a minimal Cygwin + PostgreSQL installer,
2) Have 100.000 downloads or more Windows developpers,
3) Work as a team on a Windows port.
By
On Fri, 10 May 2002 10:58:28 +0200
Iavor Raytchev [EMAIL PROTECTED] wrote:
Hello everybody,
After Marc Fournier commented, it is time for pgaccess.org to make a
decision.
It is clear the project needs the following tools.
- web site
- mailing list(s)
- cvs
- bug tracking system
Le Vendredi 10 Mai 2002 15:33, mlw a écrit :
The first time it doesn't work because of anti-virus software, they'll call
it junk. When they test performance and see that it sucks, they'll remove
the software.
Dear Mark,
PostgreSQL will work well if cygwin.dll is compiled in a separate
Some comments from Jason Tishler the Cygwin-PostgreSQL maintainer...
-Original Message-
From: Jason Tishler [mailto:[EMAIL PROTECTED]]
Sent: 10 May 2002 15:00
To: Dave Page
Cc: [EMAIL PROTECTED]
Subject: Cygwin PostgreSQL Information and Suggestions
Dave,
Would you forward
Mark kirkwood [EMAIL PROTECTED] writes:
Was the FSM size parameter set large enough to cover the amount of space
you need the system to be able to recycle --- viz, the amount used
between vacuum runs? As with most everything else in PG, the default
value is not real large: 1 pages =
Tom Lane wrote:
I don't much care for the thought of trawling every expression tree
looking for functions-returning-set during plan shutdown, so the thought
that comes to mind is to expect functions that want a shutdown callback
to register themselves somehow. Adding a list of callbacks to
Jean-Michel POURE wrote:
Le Vendredi 10 Mai 2002 15:33, mlw a écrit :
The first time it doesn't work because of anti-virus software, they'll call
it junk. When they test performance and see that it sucks, they'll remove
the software.
Dear Mark,
PostgreSQL will work well if
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
Adding a list of callbacks to
ExprContext seems pretty reasonable, but you'd also need some link in
ReturnSetInfo to let the function find the ExprContext to register
itself with. Then FreeExprContext would call the callbacks.
I've made
Hiroshi Inoue [EMAIL PROTECTED] writes:
What should the backends return for complicated rewrites ?
Well, given that we have only two or three fields to work in,
it obviously has to be a very simplified view of what happened.
But we have to define *something*.
And how should/could clients
Jan Wieck [EMAIL PROTECTED] writes:
IMHO the answer should only be a number if the rewritten
querytree list consists of one query of the same command
type. everything else has to lead into unknown.
I think you can easily generalize that to the statement that the
result
Hannu Krosing [EMAIL PROTECTED] writes:
The problem seems to be that recent changes broke updatable views for a
few users. So have these basic options:
1. revert the changes until we have a consensus on doing the right thing
(seems best to me)
Reverting is not an option, unless you want
Jan Wieck [EMAIL PROTECTED] writes:
Tom Lane wrote:
For this particular application, at least, I do not see the value ...
in fact this seems more likely to break stuff than help. If the
application does not know what the datatypes are supposed to be,
how is it going to call the prepared
mlw [EMAIL PROTECTED] writes:
Without some buy-in from the core team, I'm not sure I am willing to spend my
time on it. If someone would be willing to fund the 100 or so man-hours
required to do it, then that would be a different story.
You are not going to get any buy-in with such ridiculous
On Fri, May 10, 2002 at 11:17:39AM -0400, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Tom Lane wrote:
For this particular application, at least, I do not see the value ...
in fact this seems more likely to break stuff than help. If the
application does not know what the
Dave Page [EMAIL PROTECTED] forwards:
4. Cygwin PostgreSQL is perceived to have poor performance. I have
never done any benchmarks regarding this issue, but apparently Terry
Carlin (from the defunct Great Bridge) did:
http://archives.postgresql.org/pgsql-cygwin/2001-08/msg00029.php
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane
Sent: Friday, May 10, 2002 12:31 PM
To: Dave Page
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [HACKERS] FW: Cygwin PostgreSQL Information and Suggestions
Dave Page [EMAIL
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
Without some buy-in from the core team, I'm not sure I am willing to spend my
time on it. If someone would be willing to fund the 100 or so man-hours
required to do it, then that would be a different story.
You are not going to get any
Hi everybody,
I'm a hookie in this discussion list. Well, my intent is to get some informations
about
PostgreSQL internals to work on a project. There is an excellent GPL'ed tool to work
with Oracle
called TOra. It is as good as TOAD and SQL Navigator from Quest Software. As a meaning
of
Hi everybody,
I'm a hookie in this discussion list. Well, my intent is to get some
informations about PostgreSQL internals to work on a project. There
is an excellent GPL'ed tool to work with Oracle called TOra. It is as
good as TOAD and SQL Navigator from Quest Software. As a meaning of
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
There are DB interfaces that allow a generic application to
get a description of the result set (column names, types)
even before telling the data types of all parameters.
Our ODBC driver for example has it's
Jan Wieck [EMAIL PROTECTED] writes:
Hmm. So your vision of PREPARE would allow the backend to reply
with a list of parameter types. How would you envision that working
exactly?
I guess there's some sort of statement identifier you use to
refer to something you've prepared.
Nigel J. Andrews writes:
BTW, I had been wondering what to call the Schema tab now that that label is
required for schemas rather than design.
Design?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Hmm. So your vision of PREPARE would allow the backend to reply
with a list of parameter types. How would you envision that working
exactly?
I guess there's some sort of statement identifier you use to
refer to something
On Fri, May 10, 2002 at 09:13:20PM +0200, Peter Eisentraut wrote:
Nigel J. Andrews writes:
BTW, I had been wondering what to call the Schema tab now that that label is
required for schemas rather than design.
Design?
Thought about it, but it seems to 'active' for what's behind the tab:
Since locale support is now enabled by default, it is desirable that the
regression tests can pass if the clusters locale is not C.
As a first step I have included the following statements in pg_regress
right after the database is created:
alter database $dbname set lc_messages to 'C';
alter
A binary version of PostgreSQL for Windows should not use the cygwin dll. I
know and understand there is some disagreement with this position, but in this
I'm sure about this.
The tools used to create the binary need not be Microsoft, many venders have
used Borland or Watcom, the run of the mill
Peter Eisentraut [EMAIL PROTECTED] writes:
The assumption here is that all locales will choose the same sort order as
long as they're dealing only with the core 26 letters. This does not have
to be true in theory, but I think it works for the vast majority of
practical cases.
Not for
On Sat, 2002-05-11 at 02:25, mlw wrote:
A binary version of PostgreSQL for Windows should not use the cygwin dll. I
know and understand there is some disagreement with this position, but in this
I'm sure about this.
...
I believe we can use the cygwin development environment, and direct
On Sat, 2002-05-11 at 02:25, Peter Eisentraut wrote:
The remaining issue is the sort order. I think this can be solved for
practical purposes by creating two expected files for each affected test,
say char.out and char-locale.out. The regression test driver would try
the first one, if that
On Thu, 2002-05-09 at 14:21, Mark kirkwood wrote:
On Wed, 2002-05-08 at 01:45, Tom Lane wrote:
Which files grew exactly? (Main table, indexes, toast table, toast index?)
Here a listing (from another run - I dumped and reloaded before getting
any of that info last time...)
Tom Lane wrote:
Um. I don't like that; it assumes not only that ExecutorEnd is the only
kind of callback needed, but also that there is at most one function
per ExprContext that needs a shutdown callback. Neither of these
assumptions hold water IMO.
The design I had in mind was more like
Joe Conway [EMAIL PROTECTED] writes:
... I have not started RescanExprContext() yet, but will do it
when I address rescans in general.
I still have a couple of issues related to VIEWs that I need to figure
out, then I'll start the rescan work.
It's not unlikely that those issues are
Peter Eisentraut [EMAIL PROTECTED] writes:
For that purpose I have changed the permissions on these options to
USERSET. (I'm still debating making lc_messages SUSET, because otherwise
users can screw with admins by changing the language of the log output all
the time. Comments?)
Hm. Don't
Hannu Krosing [EMAIL PROTECTED] writes:
Was it not the case that lazy vacuum had problems freeing tuples that
have toasted fields ?
News to me if so.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the
Tom Lane escribió:
Peter Eisentraut [EMAIL PROTECTED] writes:
The assumption here is that all locales will choose the same sort order as
long as they're dealing only with the core 26 letters.
Nope. For instance, on HPUX I get this sort order in English:
[...]
because the Spanish
Alvaro Herrera [EMAIL PROTECTED] writes:
HPUX's behaviour is broken, because in spanish LL (as well as CH)
stopped being a special symbol some five years ago (it used to be
treated as one collating element sorted after L, so HPUX behaviour was
right then).
Well, this is an old release ;-)
Jan Wieck wrote:
Hiroshi Inoue wrote:
Tom Lane wrote:
What should the backends return for complicated rewrites ?
And how should/could clients handle the results ?
It doesn't seem easy to me and it seems a flaw of rule
system. Honestly I don't think that the psqlodbc driver
can
[Cc:ed to hackers]
(trying select convert(lower(convert('X', 'LATIN1')),'LATIN1','UNICODE');)
Ok, this is working now (I cann't reproduce why not at the first time).
Good.
Is it planned to implement it so that I can write lower()/ upper() for multibyte
according to SQL standard (without
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
... I have not started RescanExprContext() yet, but will do it
when I address rescans in general.
I still have a couple of issues related to VIEWs that I need to figure
out, then I'll start the rescan work.
It's not unlikely that those
I just did a fresh build from current cvs and found the following
regression from 7.2:
create table test (cola bigint);
update test set cola = 100;
In 7.3 the update results in the following error:
ERROR: column cola is of type 'bigint' but expression is of type
'double precision'
59 matches
Mail list logo
