Tony Caduto schrieb:
Hi,
I want to give something back(I would give a donation but sales are poor
:-( ,so I am offering to any verified Postgresql developer(by verified I
mean your name shows up on this list a LOT ) a free copy of PG
Lightning Admin.
Does this mean postgres developer who
I did a dump of a 7.4.11 database using the 8.1.2 pg_dumpall. I got
this at the top of the dump:
...
...
CREATE ROLE support;
ALTER ROLE support WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB
LOGIN PASSWORD 'md5';
...
...
CREATE ROLE support;
ALTER ROLE
On 1/23/06, Tom Lane [EMAIL PROTECTED] wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Attached is a patch that merges postmaster and postgres into just a
postmaster command.
I had some second thoughts about this, specifically about which
direction do we really want to go in. With this
What would be the cause of this error after upgrading from pgsql 7.4 to 8.1?
usatest=# SELECT lexize[1] FROM lexize('en_stem', 'bacon');
ERROR: cache lookup failed for function 861011
Does tsearch2 need to somehow be tweaked after the upgrade?
Chris
---(end of
Its not a macro.I meant that the code generated by
AC_REPLACE_FUNCS([getaddrinfo]) by configure.in for "configure"does not have
"#include netdb.h". Hence function is not detected(unresolved
getaddrinfo).Hence I thought AC_TRY_LINK could give test program
instead of AC_REPLACE_FUNCS taking
On Tue, Jan 24, 2006 at 02:33:13PM +0530, R, Rajesh (STSD) wrote:
Its not a macro.
I meant that the code generated by AC_REPLACE_FUNCS([getaddrinfo]) by
configure.in for configure
does not have #include netdb.h. Hence function is not
detected(unresolved getaddrinfo).
Hence I thought
Hi Tony,
I am using PD Admin as a client, to connect PostgresSQL in windows
environment, It is not much flexibale.
I am highly obliged if i can get free copy of PG Lightning Admin.
Regards,
AFTAB ALAM
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
On Tuesday 24 January 2006 02:03, Christopher Kings-Lynne wrote:
What would be the cause of this error after upgrading from pgsql 7.4 to
8.1?
usatest=# SELECT lexize[1] FROM lexize('en_stem', 'bacon');
ERROR: cache lookup failed for function 861011
Does tsearch2 need to somehow be tweaked
sorry. It is a macro.so, would it be better to
check for the macroas suggested by Tom or go with this patch$ diff -r configure.in configure.in.new918a919
AC_MSG_CHECKING([for getaddrinfo])920c921,926
AC_REPLACE_FUNCS([getaddrinfo])--- AC_TRY_LINK([#include
netdb.h #include
assert.h],
On Thu, Jan 19, 2006 at 00:06:41 -0500,
Tom Lane [EMAIL PROTECTED] wrote:
The problem with SSN is that somebody other than you controls it.
If you are the college registrar, then you control the student's
registration number, and you don't have to change it. In fact, guess
what: you
On Thu, Jan 19, 2006 at 09:53:11 -0500,
[EMAIL PROTECTED] wrote:
Yes. Representation of the DNA is probably best. But - that's a lot of
data to use as a key in multiple tables. :-)
On a simple level, this would be a problem for twins.
There are other complications as well. People are going
pgd?
Gustavo.
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
On Tue, 24 Jan 2006, Christopher Kings-Lynne wrote:
What would be the cause of this error after upgrading from pgsql 7.4 to 8.1?
usatest=# SELECT lexize[1] FROM lexize('en_stem', 'bacon');
ERROR: cache lookup failed for function 861011
Does tsearch2 need to somehow be tweaked after the
My read is such that he is using Senna as follows (where external means outside of PostgreSQL):1. Create external FTI2. BEGIN TRANS3a. Insert record into PostgreSQL3b. Insert record into Senna4. Commit
His problem is that the PostgreSQL record (3a) *could* be rolled-back after he adds them to the
* Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
H...actually. It's because I have a user called 'support' and a
group called 'support'.
Seems like it needs a fix...
Have you got a suggestion on just how to fix it...? Debian's
pg_upgradecluster bails out with an error when it
On Tue, 2006-01-24 at 09:44 -0500, Stephen Frost wrote:
* Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
H...actually. It's because I have a user called 'support' and a
group called 'support'.
Seems like it needs a fix...
Have you got a suggestion on just how to fix it...?
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
H...actually. It's because I have a user called 'support' and a
group called 'support'.
This was discussed already. It's a corner case we didn't really think
about while designing roles. It's possible to support this: the group
and the
On Tue, 2006-01-24 at 10:05 -0500, Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
H...actually. It's because I have a user called 'support' and a
group called 'support'.
It's possible to support this: the group
and the user will now really be the same entity, ie a
Andrew Dunstan [EMAIL PROTECTED] writes:
On Tue, 2006-01-24 at 10:05 -0500, Tom Lane wrote:
It's possible to support this: the group
and the user will now really be the same entity, ie a role that has both
its own login privileges and members.
Assuming you actually want to unify the two
Am Dienstag, 24. Januar 2006 15:44 schrieb Stephen Frost:
Have you got a suggestion on just how to fix it...? Debian's
pg_upgradecluster bails out with an error when it discovers this
situation but I don't think it'd be sensible for pg_dump to do that...
Why not? If the backup cannot be made
Hi,
it's a renewed locale per database patch. Unfortunately, i've not found
clean way to rebuild database indexes automatically, if locale settings
of two databases (created and template) are differs. Now it's only
raises a NOTICE. So, if anyone has a right notion about it - let will
express.
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Dienstag, 24. Januar 2006 15:44 schrieb Stephen Frost:
Have you got a suggestion on just how to fix it...? Debian's
pg_upgradecluster bails out with an error when it discovers this
situation but I don't think it'd be sensible for pg_dump to do
We've had previous discussions about how the distinction between INET
and CIDR isn't very well thought out, for instance
http://archives.postgresql.org/pgsql-hackers/2005-01/msg01021.php
http://archives.postgresql.org/pgsql-hackers/2006-01/msg00233.php
The basic problem is that the code is
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Attached is a patch that merges postmaster and postgres into just a
postmaster command.
I had some second thoughts about this, specifically about which
direction do we really want to go in. With this patch, it no longer
really
On Tue, Jan 24, 2006 at 01:23:17PM -0500, Tom Lane wrote:
Without the flag, it's okay for cidr-to-inet to be a binary-compatible (no
function) conversion. However, inet-to-cidr has to either zero out bits
to the right of the netmask, or error out if any are set. Joachim Wieland
posted a
After reading the post on -patches proposing that MemSet be changed to
use long instead of int32 on the grounds that a pair of x86-64 linux
boxes took less time to execute the long code 64*10^6 times[1], I took a
look at how the testcode performed on AIX with gcc. While the switch to
long did
On Tue, Jan 24, 2006 at 05:24:28PM -0500, Seneca Cunningham wrote:
After reading the post on -patches proposing that MemSet be changed to
use long instead of int32 on the grounds that a pair of x86-64 linux
boxes took less time to execute the long code 64*10^6 times[1], I took a
look at how
On 2006-01-24, Tom Lane [EMAIL PROTECTED] wrote:
Without the flag, it's okay for cidr-to-inet to be a binary-compatible (no
function) conversion. However, inet-to-cidr has to either zero out bits
to the right of the netmask, or error out if any are set. Joachim Wieland
posted a patch that
How about an option to map groups whose names conflict with user names
using a prefix mechanism?
e.g. --map-conflicting-groups=gr_
Then in Christopher's example his support group would become the role
gr_support.
No bad, have to change some application code then as well...
Chris
On Tue, Jan 24, 2006 at 10:42:17AM -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
On Tue, 2006-01-24 at 10:05 -0500, Tom Lane wrote:
It's possible to support this: the group
and the user will now really be the same entity, ie a role that has both
its own login privileges
This is exactly what I had in mind:
split the types
zero out the bits going to cidr
no change going to inet
make functions take inet, which as not cast change
---
Tom Lane wrote:
We've had
31 matches
Mail list logo