On Fri, 2008-09-19 at 17:33 -0400, Greg Smith wrote:
On Fri, 19 Sep 2008, Greg Stark wrote:
This is a good example of why running with assertions enabled on production
might not be a good idea. But it's also a good example of why we should do
our performance testing with assertions
On Fri, 2008-09-19 at 17:47 -0400, Tom Lane wrote:
Greg Smith [EMAIL PROTECTED] writes:
On Fri, 19 Sep 2008, Greg Stark wrote:
This is a good example of why running with assertions enabled on
production
might not be a good idea. But it's also a good example of why we should do
our
http://pqxx.org/development/libpqxx/
I'm in the process of creating a macport for libpqxx. I could use
some help from anyone with experience in building postgresql or
libpqxx on OSX, esp. against the macport libraries.
Thanks, Darren
--
Sent via pgsql-hackers mailing list
On Fri, Sep 19, 2008 at 10:38 PM, Josh Berkus [EMAIL PROTECTED] wrote:
That's kind of what I'm doing now. But I'm wondering if I should
bother with pgFoundry at all. It seems pretty dead (see Josh Berkus's
reply).
Actually, pgFoundry remains extremely popular. Currently, we're getting an
On Sat, Sep 20, 2008 at 7:30 AM, Darren Weber
[EMAIL PROTECTED] wrote:
http://pqxx.org/development/libpqxx/
I'm in the process of creating a macport for libpqxx. I could use
some help from anyone with experience in building postgresql or
libpqxx on OSX, esp. against the macport libraries.
Dave Page wrote:
Well that's not strictly true - I persuaded one of the GForge
developers to work on the upgrade. As far as I'm aware, we're still
waiting for the hardware/OS platform to be sorted out after some
initial problems. I suspect JD will tell me something different though
- that being
On Sat, Sep 20, 2008 at 8:37 AM, Joshua D. Drake [EMAIL PROTECTED] wrote:
Dave Page wrote:
Well that's not strictly true - I persuaded one of the GForge
developers to work on the upgrade. As far as I'm aware, we're still
waiting for the hardware/OS platform to be sorted out after some
Greg Sabino Mullane wrote:
I guess I don't understand where Joe User was supposed to have gotten
the message that 7.4 was on its last legs. If anything, the fact that
it is on patchlevel 21 suggests otherwise. Us hackers and developers
shudder at seeing a 7.4 database, but there are plenty of
[1] Make a consensus that different security mechanisms have differences
in its decision making, its gulanuality and its scope
I think it is the most straightforward answer.
As operating system doing, DAC and MAC based access controls should be
independently applied on accesses from users,
On Fri, 19 Sep 2008, Gevik Babakhani [EMAIL PROTECTED] writes:
Has there been any idea to port PG to a more modern programming language
like C++? Of course there are some minor obstacles like a new OO design,
this being a gigantic task to perform and rewriting almost everything etc...
I am
On Fri, 2008-09-19 at 16:37 -0400, D'Arcy J.M. Cain wrote:
On Fri, 19 Sep 2008 20:57:36 +0100
Dave Page [EMAIL PROTECTED] wrote:
On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani [EMAIL PROTECTED] wrote:
Has there been any idea to port PG to a more modern programming language
like C++? Of
On Sat, 20 Sep 2008 13:47:10 +0300
Hannu Krosing [EMAIL PROTECTED] wrote:
On Fri, 2008-09-19 at 16:37 -0400, D'Arcy J.M. Cain wrote:
I don't think that we should rush into any one language without
checking the alternatives. Personally I think we should port everything
to Intercal.
My
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2008-09-19 at 17:47 -0400, Tom Lane wrote:
Well, there are certain things that --enable-cassert turns on that are
outrageously expensive; notably CLOBBER_FREED_MEMORY and
MEMORY_CONTEXT_CHECKING. It wouldn't be too unreasonable to decouple
those
Shane Ambler [EMAIL PROTECTED] writes:
The few postings I have noticed with users running 7.4 has been with a
release several less than the newest. ...
Supporting old versions is a great and noble thing but there comes a
time when it is a waste of resources because the effort goes unused.
On Sat, 2008-09-20 at 11:28 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2008-09-19 at 17:47 -0400, Tom Lane wrote:
Well, there are certain things that --enable-cassert turns on that are
outrageously expensive; notably CLOBBER_FREED_MEMORY and
Hi Dave,
Thanks for getting back to me. Please find attached a draft Portfile
for libpqxx-2.6.9 (the stable version). It's easy to read the
Portfile to see what is going on. I think it should work fine, but I
would appreciate any advice about any configure options that should be
enabled.
I've
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane wrote:
The suggestion I started this thread with amounted to not bothering with
pushing 7.4.x updates in update cycles where we'd made no serious bug
fixes in it; which is a very long way from desupport. Maybe an
appropriate
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane wrote:
The suggestion I started this thread with amounted to not bothering with
pushing 7.4.x updates in update cycles where we'd made no serious bug
fixes in it; which is a very long way from desupport.
Ron Mayer wrote:
Tom Lane wrote:
...GUC that selected PG traditional, SQL-standard... interval output
format seems like it could be a good idea.
This is an update to the earlier SQL-standard-interval-literal output
patch that I submitted here:
Joshua D. Drake wrote:
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane wrote:
The suggestion I started this thread with amounted to not bothering with
pushing 7.4.x updates in update cycles where we'd made no serious bug
fixes in it; which is a very
Magnus Hagander wrote:
Shall we set an exact date, such as October 1, 2009?
Let's include 8.0 in that announcement so we aren't having this
discussion again in a year.
Are we ready enough to actually put a *timeline* on the website?
Meaning, can we already put in preliminary dates for *all*
Joshua D. Drake wrote:
3 years - Maintenance mode only
5 years - End of life
Of course we need to define what maintenance mode only means.
We effectively put each release into maintenance mode on day 1, ISTM.
cheers
andrew
--
Sent via pgsql-hackers mailing list
Andrew Dunstan wrote:
Joshua D. Drake wrote:
3 years - Maintenance mode only
5 years - End of life
Of course we need to define what maintenance mode only means.
We effectively put each release into maintenance mode on day 1, ISTM.
True enough.
Joshua d. Drake
cheers
andrew
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 20 sept. 08 à 09:42, Dave Page a écrit :
On Sat, Sep 20, 2008 at 8:37 AM, Joshua D. Drake
[EMAIL PROTECTED] wrote:
Dave Page wrote:
Well that's not strictly true - I persuaded one of the GForge
developers to work on the upgrade. As far
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Who can resist the programming language game?
Le 19 sept. 08 à 22:37, D'Arcy J.M. Cain a écrit :
On Fri, 19 Sep 2008 20:57:36 +0100
Dave Page [EMAIL PROTECTED] wrote:
On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani [EMAIL PROTECTED]
wrote:
2008/9/20 Joshua D. Drake [EMAIL PROTECTED]:
Andrew Dunstan wrote:
Joshua D. Drake wrote:
3 years - Maintenance mode only
5 years - End of life
Of course we need to define what maintenance mode only means.
We effectively put each release into maintenance mode on day 1, ISTM.
True
On Sat, 2008-09-20 at 09:06 -0400, D'Arcy J.M. Cain wrote:
On Sat, 20 Sep 2008 13:47:10 +0300
Hannu Krosing [EMAIL PROTECTED] wrote:
On Fri, 2008-09-19 at 16:37 -0400, D'Arcy J.M. Cain wrote:
I don't think that we should rush into any one language without
checking the alternatives.
Andrew Dunstan [EMAIL PROTECTED] writes:
Joshua D. Drake wrote:
Of course we need to define what maintenance mode only means.
We effectively put each release into maintenance mode on day 1, ISTM.
Well, that would depend on your definition of maintenance mode ;-)
Your statement would be true
Joshua D. Drake [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
Are we ready enough to actually put a *timeline* on the website?
I would think so. IMO:
3 years - Maintenance mode only
5 years - End of life
I'm not really in favor of a one-size-fits-all approach to this.
Our various
Marko Kreen wrote:
In addition to breaking standard security policy, dblink exposes
.pgpass/pg_service.conf contents of the OS user database is running
under to the non-privileged database user. (Esp. passwords)
I took a look and can partially see Marko's point. The scenario exists
within
I'm clearly out of practice -- this time with the attachment
Marko Kreen wrote:
In addition to breaking standard security policy, dblink exposes
.pgpass/pg_service.conf contents of the OS user database is running
under to the
Hello.
Is it possible to create a foreign key constraint for ALL elements of
an array field?
CREATE TABLE a(id INTEGER);
CREATE TABLE b(id INTEGER, a_ids INTEGER[]);
Field b.a_ids contains a list of ID's of a table. I want to ensure
that each element in b.a_ids exists in a in any time. Is it
Joe Conway [EMAIL PROTECTED] writes:
I took a look and can partially see Marko's point. The scenario exists
within this context:
1. superuser installs dblink on db1, running on postgres server
under the superuser account
2. superuser has .pgpass file
3. the superuser .pgpass file is set
Hello.
Utility pg_dump dumps the identical database schemas not always
identically: sometimes it changes an order of SQL statements.
E.g.:
1. Dump of database A:
ALTER TABLE xxx ADD CONSTRAINT ...;
ALTER TABLE yyy ADD CONSTRAINT ...;
2. Dump of database B which has identical structure as A
Dmitry Koterov [EMAIL PROTECTED] writes:
Utility pg_dump dumps the identical database schemas not always
identically: sometimes it changes an order of SQL statements.
Please provide a concrete example. The dump order for modern servers
(ie, since 7.3) is by object type, and within a type by
Tom Lane wrote:
I think there is an alternative solution, if we are only going to patch
this in 8.4 and up: provide a new libpq conninfo-string option saying
not to use .pgpass, and have dblink add that to the passed-in conninfo
string instead of trying to check after the fact. Then we aren't
On Sat, Sep 20, 2008 at 8:38 PM, Dmitry Koterov [EMAIL PROTECTED] wrote:
Hello.
Is it possible to create a foreign key constraint for ALL elements of
an array field?
CREATE TABLE a(id INTEGER);
CREATE TABLE b(id INTEGER, a_ids INTEGER[]);
Field b.a_ids contains a list of ID's of a table.
Joe Conway [EMAIL PROTECTED] writes:
Good point -- I'll look into that and post something tomorrow. How does
requirepassword sound for the option? It is consistent with
requiressl but a bit long and hard to read. Maybe require_password?
Well, no, because it's not requiring a password.
PlanState.has_recursivescan seems like a complete kluge. Can't it just be
removed? It looks to me like it is working around bugs that hopefully aren't
there anymore. There is certainly no reason why a recursive CTE should be
more in need of rescanning than any other kind of plan.
I don't
Tatsuo Ishii [EMAIL PROTECTED] writes:
PlanState.has_recursivescan seems like a complete kluge. Can't it just be
removed? It looks to me like it is working around bugs that hopefully aren't
there anymore. There is certainly no reason why a recursive CTE should be
more in need of rescanning
On Sun, Sep 21, 2008 at 04:38:56AM +0400, Dmitry Koterov wrote:
Hello.
Is it possible to create a foreign key constraint for ALL elements of
an array field?
Whether it's possible or not--it probably is--it's a very bad idea.
Just normalize :)
Cheers,
David.
--
David Fetter [EMAIL
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
Are we ready enough to actually put a *timeline* on the website?
I would think so. IMO:
3 years - Maintenance mode only
5 years - End of life
I'm not really in favor of a one-size-fits-all approach to this.
David Fetter wrote:
On Sun, Sep 21, 2008 at 04:38:56AM +0400, Dmitry Koterov wrote:
Hello.
Is it possible to create a foreign key constraint for ALL elements of
an array field?
Whether it's possible or not--it probably is--it's a very bad idea.
Just normalize :)
+1
Cheers,
David.
--
43 matches
Mail list logo
