Hi.
Where I can download sources of win32 port?
Can I help for win32 port?
Thanks.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can
If you're talking about running as a backend for SMS you can be almost
certain it will not work. That one today works only with MS SQL (not
Oracle, DB2 or anybody else that already have native Win32 versions),
and probably uses a *lot* of the non standard features in it. IIRC the
beta of the new
When I run createlang plpgsql template1
on linux 7.3 (pg version 7.3.1), it failed -
createlang plpgsql template1
ERROR: stat failed on file '$libdir/plpgsql': No such file or directory
createlang: language installation failed
Can someone point me where could go wrong?
thanks.
johnl
Shridhar Daithankar [EMAIL PROTECTED] writes:
I would say keep range of user specified ids and automatically generated ids
exclusive to each other.
No, that won't do. The principal reason why we keep the explicit SYSID
option around at all is so that a DBA can deliberately recreate a user
John Liu [EMAIL PROTECTED] writes:
When I run createlang plpgsql template1
on linux 7.3 (pg version 7.3.1), it failed -
createlang plpgsql template1
ERROR: stat failed on file '$libdir/plpgsql': No such file or directory
createlang: language installation failed
What does 'pg_config
Shridhar Daithankar [EMAIL PROTECTED] writes:
If this is the idea, I suggest that all user/group transactions be logged. So
that admin can go thr. them to find out what was id of an user at any given
time. Otherwise admin is not likely to keep list of uids handy and in tough
situation,
John Liu [EMAIL PROTECTED] writes:
Thanks, fixed. The problem was
caused -
there's a postgreSQL came with the
Redhat server, but I tried to install one
only used by a specific user, I set
LD_LIBRARY_PATH in this user's profile.
pg_config --pkglibdir points to the correct
lib dir, but when
Bruce Momjian [EMAIL PROTECTED] writes:
The reason I was being cautious is to handle cases where people are
poking in pg_shadow directly.
If they're poking pg_shadow directly, I think it's up to them to avoid
or cope with sysid conflicts (the unique indexes on the table will
prevent the worst
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The reason I was being cautious is to handle cases where people are
poking in pg_shadow directly.
If they're poking pg_shadow directly, I think it's up to them to avoid
or cope with sysid conflicts (the unique indexes on the table
I have an idea for an aggregate function (actually a pair) that would be very
useful. It's something I've wanted very frequently with Oracle and other
databases and while it's possible to implement in SQL it's hard to do
efficiently. Whereas it would be really easy for the database to do it
On Fri, Jan 17, 2003 at 13:39:11 -0500,
Greg Stark [EMAIL PROTECTED] wrote:
So it would be possible to say for example:
select min(column1),lookup_min(column1,column2) from tab
to do the equivalent of:
select column1,column2 where column1=(select min(column1) from tab) limit 1
-Original Message-
From: Magnus Hagander [mailto:[EMAIL PROTECTED]]
Sent: 17 January 2003 11:30
To: Justin Clift; PostgreSQL Hackers Mailing List
Subject: Re: [HACKERS] PostgreSQL 7.4 and Microsoft's SMS
The *current* psql client will already install using SMS.
Don't know
Bruno Wolff III [EMAIL PROTECTED] writes:
On Fri, Jan 17, 2003 at 13:39:11 -0500,
Greg Stark [EMAIL PROTECTED] wrote:
So it would be possible to say for example:
select min(column1),lookup_min(column1,column2) from tab
to do the equivalent of:
select column1,column2 where
[EMAIL PROTECTED] wrote:
snip
I have strongly considered doing this, and even started on the project some
time ago. (I've stopped now). At first I wanted to add 7.3 and 7.4 features
to a 7.2 psql. Then I considered writing a master psql that could handle
any backend. In the end, however, I
Okay,
I have finally extracted out a patch that applied to a 7.2.1 tree get's
me something that compiles and passes all regression tests on RedHat
Linux and Windows 2000.
To clearify upfront, even if the build process of this port uses a few
cygwin tools, the final executables and libraries do
On 17 Jan 2003 15:12:58 -0500, Greg Stark [EMAIL PROTECTED] wrote:
SELECT item.*, store.*, x.lowest_price
FROM item, store, (
SELECT item_id,
min(price) AS lowest_price,
lookup_min(price,store_id) AS lowest_price_store
FROM items_for_sale
Greg Stark [EMAIL PROTECTED] writes:
select min(column1),lookup_min(column1,column2) from tab
One small problem is that we only support single-argument aggregates.
As of 7.3 this is no longer wired into the system catalog layout, but
it's still wired into various internal datastructures. Anyone
On Thursday 16 January 2003 12:23, Neil Conway wrote:
On Thu, 2003-01-16 at 11:42, D'Arcy J.M. Cain wrote:
Is [Oracle RAC] really as simple as it sounds or would we just be
giving up the other two for a new set of problems.
That's a question you should be asking to an authority on Oracle
Manfred Koizar [EMAIL PROTECTED] writes:
Greg, we already have this feature, just the syntax is a bit different :-)
SELECT DISTINCT ON (item_id) item_id,
price AS lowest_price,
store_id AS lowest_price_store
FROM items_for_sale
WHERE
Jan Wieck wrote:
As a PostgreSQL coreteam member I want to thank my employer, the
PeerDirect Corporation, for contributing this work, which IMHO is an
important step for PostgreSQL.
Yes, a very important step. A big thank you to PeerDirect.
What we need from here are some ideas how this port
Jochem van Dieten wrote:
everything. Even when connecting to a 7.3 server the problems (no schema
support etc.) are far outweighted by the advantages of having a
lightweight (just libpq.dll + psql.exe, no cygwin, no installation)
client tool. But it would be nice if schema support etc. was
On Thursday 16 January 2003 20:54, Christopher Kings-Lynne wrote:
toss PostgreSQL in favour of Oracle with Remote Access Cluster (RAC)
software.
You mean Real Application Clusters?
Oops, yes.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
On Thursday 16 January 2003 11:59, Adrian 'Dagurashibanipal' von Bidder wrote:
On Thu, 2003-01-16 at 17:42, D'Arcy J.M. Cain wrote:
We are also looking at hardware solutions, multi-CPU PCs with tons (24GB)
of memory. I know that memory will improve access if it prevents
swapping but how
On Thursday 16 January 2003 22:47, Justin Clift wrote:
Although we haven't wanted to release a 7.2.4, and have instead
encouraged people to upgrade to 7.3.x, there are places out there who's
applications aren't compatible with 7.3.x and would also need to upgrade
them as well.
Incidentally,
Lamar Owen [EMAIL PROTECTED] writes:
Incidentally, has anyone else noticed the security update onslaught from Red
Hat for older PostgreSQL versions? They even backported the fixes to 6.5.3
from Red Hat 6.2 (as well as for 7.0 and 7.1 as released in the respective
Red Hat Linux versions).
Tom Lane wrote:
Currently, the default sysid assigned to a user or group is computed as
max(sysid)+1. We've seen a couple of complaints now from people who
deleted their newest user, made another user, and found that permissions
from the deleted user carried over to the new one.
It seems
With ever more larger businesses adopting PostgreSQL, and that leading
on to more places having several versions of PostgreSQL in operation
simultaneously (i.e. development vs production) we're probably going to
need to give psql the ability to handle whichever version of the PG
backend it
On Saturday 18 January 2003 00:08, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
Incidentally, has anyone else noticed the security update onslaught from
Red Hat for older PostgreSQL versions? They even backported the fixes to
6.5.3 from Red Hat 6.2 (as well as for 7.0 and 7.1 as
Bruce Momjian [EMAIL PROTECTED] writes:
OK. Do we have many people left upgrading from pg_dump's that COPY into
pg_shadow?
Hm, good point. I had forgotten we ever did that ;-)
It looks like 7.0.* was the last release where pg_dumpall did that.
Is that far enough back?
[ looks further... ]
Jan is working on the port and should be posting it to the patches list
in the next few days. After that, we will all look over the patch, port
it from 7.2.1 to CVS HEAD, and make improvements before applying to CVS
HEAD.
Stay subscribed to hackers and you will see all the activity as soon as
On Fri, Jan 17, 2003 at 11:38:24AM -0500, Bruce Momjian wrote:
Tom Lane wrote:
A small difficulty is that explicitly-specified sysids could conflict
with sysids generated later by the sequence. We could perhaps fix this
by forcing up the sequence setting to be at least as large as an
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK. Do we have many people left upgrading from pg_dump's that COPY into
pg_shadow?
Hm, good point. I had forgotten we ever did that ;-)
It looks like 7.0.* was the last release where pg_dumpall did that.
Is that far enough back?
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
This way, we don't need to bother with
touching the sequence at all during a CREATE USER with explicit sysid.
Well, the problem is that this could still cause the reuse of a deleted
user, no? Wasn't that the problem we were
On Fri, 2003-01-17 at 12:36, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
This way, we don't need to bother with
touching the sequence at all during a CREATE USER with explicit sysid.
Well, the problem is that this could still cause the reuse of a deleted
user, no? Wasn't
Have we decided it's really too difficult to remove all references to a
given sysid when the user is dropped? It seems like we're creating
multiple new problems in an effort to workaround one existing problem.
Robert Treat
On Fri, 2003-01-17 at 12:38, Bruce Momjian wrote:
Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
Have we decided it's really too difficult to remove all references to a
given sysid when the user is dropped?
Getting at objects in other databases is considerably less practical
than anything we've discussed here. At a minimum I think it would
require
On Fri, 2003-01-17 at 14:32, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
Have we decided it's really too difficult to remove all references to a
given sysid when the user is dropped?
Getting at objects in other databases is considerably less practical
than anything we've
Robert Treat [EMAIL PROTECTED] writes:
On Fri, 2003-01-17 at 14:32, Tom Lane wrote:
Getting at objects in other databases is considerably less practical
than anything we've discussed here.
Perhaps you don't allow the removal unless all databases came up clean.
You can have the db admin go in
My idea was to go through the patch and break it out into the items it
addresses:
fork/exec
loop rename test
handle \r in COPY
copydir for cp -r
backslash tests
rmdir not recursive for rm -r
shared memory could map to new address in
Bruce Momjian writes:
OK, you mentioned you want to put IPv6 addresses in pg_hba.conf even if
the OS doesn't support it. How do others feel about that.
We do leave the local in there even if the OS doesn't support it.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end
Peter Eisentraut wrote:
Bruce Momjian writes:
OK, you mentioned you want to put IPv6 addresses in pg_hba.conf even if
the OS doesn't support it. How do others feel about that.
We do leave the local in there even if the OS doesn't support it.
Good point. I will have the IPv6 be in
Tom Lane wrote:
Red Hat 6.2 is still nominally supported (until March 31, it says here)
so I suppose there's a corporate compulsion to back-patch anything
that's labeled a security issue. But let's get real ... PG 6.anything
is stone-age code now.
regards, tom lane
42 matches
Mail list logo
