Gaetano Mendola [EMAIL PROTECTED] writes:
Comments are welcomed.
Well as long as you're asking...
Email domains are case insensitive, but the left hand side is case sensitive.
That's the only part that's hard to handle using a text data type, it would be
kind of neat if the email operators
Greets,
Is there a way for me to clean up fn_extra in flinfo when the function is not
a Set Returning Function(SRF)?
I know I can use RegisterExprContextCallback and the RSI's econtext to register a
callback
for SRFs, but this--or similar functionality--does not appear to be available for
Tatsuo Ishii wrote:
initdb could even emit a warning if the --encoding option was
used without also specifying --no-locale.
Please don't do that. Most Asian chasets does not work with locale
enabled PostgreSQL installation. i.e. it returns WRONG SELECT
results. I've been telling this to Japanese
Marc G. Fournier wrote:
On Mon, 17 May 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
Agreed, but you are a me too, not a huge percentage of our userbase.
How do you know? Have you polled our complete userbase?
Basically, after 6-7 months of development, I want more than a vacuum
patch and
Tatsuo Ishii wrote:
Is there any security risk if we enable tcpip_socket by default? We
restrict connection from localhost only by default so I think enabling
tcpip_socket adds no security risk. Please correct me if I am wrong.
Bruce Momjian wrote:
Right, and 7.5 will ship with tcp
On Mon, 17 May 2004 05:29 pm, Marko Karppinen wrote:
If the default will be to listen on all interfaces, not just 127.0.0.1,
then this IS a security risk. And if that's not the plan, what good does
this change do? Any real use of tcp would still require a
configuration
change anyway.
From
On 17. touko 2004, at 10:40, Tatsuo Ishii wrote:
Consider a program using JDBC on localhost. It can only reach to
PostgreSQL via TCP/IP.
Ah! Of course. That makes sense, and listening on 127.0.0.1 never
hurt anyone (except, of course, the tinfoil hat crowd nmapping
localhost in a frenzy...)
mk
Tatsuo Ishii wrote:
Is there any security risk if we enable tcpip_socket by default? We
restrict connection from localhost only by default so I think enabling
tcpip_socket adds no security risk. Please correct me if I am wrong.
Bruce Momjian wrote:
Right, and 7.5 will ship with tcp and localhost
Marko Karppinen wrote:
If the default will be to listen on all interfaces, not just
127.0.0.1, then this IS a security risk. And if that's not the plan,
what good does this change do? Any real use of tcp would still
require a
configuration
change anyway.
Some interfaces, most notably JDBC,
Shridhar Daithankar wrote:
Hi all,
Just stumbled upon this. just an FYI,
http://www.microsoft.com/sql/yukon/productinfo/top30features.asp
Notice the Snapshot Isolation. Sounds like MVCC for MSSQL?
Regards,
Andreas
---(end of broadcast)---
TIP 5:
Dear Tom,
I wish to submit a small patch so that server includes and
all necessary configuration files could be installed *by default*.
There is a reason why install-all-headers is not the default.
Sure. I hope so!
I'm questionning the pros and cons. I'm arguing that the cons against the
...
Another thing is that it might make more sense to sort email addresses by
domain first (case insensitively of course), then by left hand side (case
sensitively). Since the domain is really the most significant bit. This
is also convenient for many systems like email since they perform
Hi all,
Attached is a patch against HEAD implementing tablespaces.
I've done some testing on Linux and BSD. I've also compiled without
HAVE_SYMLINK defined -- which determines whether or not tablespaces are
available.
The reason for this is that symlinks are used extensively to simplify
access
Marko Karppinen said:
Tatsuo Ishii wrote:
Is there any security risk if we enable tcpip_socket by default? We
restrict connection from localhost only by default so I think
enabling tcpip_socket adds no security risk. Please correct me if I
am wrong.
Bruce Momjian wrote:
Right, and 7.5 will
Dear hackers,
Agreed. I would also like to see Makefile.global installed.
pg_config.h has C-level configs, and Makefile.global has the
Makefile-level configs.
There is also config.status which is definitely of interest as it
allows to recreate the build tree, and which is not installed by
Hans-Jürgen Schönig wrote:
All the clients that I deal with on a daily basis generally care about is
performance ... that is generally what they upgrade for ... so, my
'educated guess' based on real world users is that Win32, PITR and nested
transactions are not important ... tablespaces,
Gavin Sherry wrote:
Alternative database location:
Should this code be removed now?
Yes, I believe we agreed on this. One of the committers will take care
of that.
The only downside to removal is that folks without symlinks (I believe
Win32 only) will loose that functionality with nothing
Marc G. Fournier wrote:
On Sun, 16 May 2004, Bruce Momjian wrote:
I personally don't think Win32 is enough of a new feature either, but
others disagree.
Jan, correct me if I'm wrong ... Jan's point is that we have enough
already to warrant a beta on June 1st, even without Win32 ... Win32 (or
any
Jan Wieck wrote:
Christopher Kings-Lynne wrote:
Jan, correct me if I'm wrong ... Jan's point is that we have enough
already to warrant a beta on June 1st, even without Win32 ... Win32 (or
any of the other stuff, like PITR/tablespaces) would be icing on the cake
...
I think we're
It is too late to think about pushing back another month. We had this
discussion already. June 1 is it.
I thought the outcome of that discussion was June 15 ?
Can we try to do the 2PC patch now instead of waiting for subtransactions ?
Andreas
---(end of
Bruce Momjian wrote:
Tom Lane wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
The straightforward pg_clog lookup is still in transam.c,
but has been deactivated:
* Now this func in shmem.c and gives quality answer by scanning
* PGPROC structures of all running backend. - vadim 11/26/96
What
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruno Wolff III wrote:
| On Sun, May 16, 2004 at 04:36:55 +0200,
| Gaetano Mendola [EMAIL PROTECTED] wrote:
|
|The type is indexable and provide also conversion methods:
|
|text -- email
|and the operator , is possible use it in select like:
|
|
|
Greg Stark wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
Comments are welcomed.
Well as long as you're asking...
Email domains are case insensitive, but the left hand side is case sensitive.
That's the only part that's hard to handle using a text data type, it would be
kind of neat if the
Robert Treat wrote:
On Monday 17 May 2004 08:21, Bruce Momjian wrote:
Hans-J?rgen Sch?nig wrote:
I am still wondering about two things:
Somebody has posted a 2PC patch - I haven't seen too many comments
He is waiting for nested transactions to be committed so he can merge
his work
On Monday 17 May 2004 08:21, Bruce Momjian wrote:
Hans-Jürgen Schönig wrote:
I am still wondering about two things:
Somebody has posted a 2PC patch - I haven't seen too many comments
He is waiting for nested transactions to be committed so he can merge
his work in.
I was thinking about
-Original Message-
From: Gaetano Mendola [mailto:[EMAIL PROTECTED]
Sent: 17 May 2004 16:02
To: Bruno Wolff III
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Email data type
About the domain literals, I think to validate it in the near
future, rejecting private subnet
Dear Tom,
(2) Although I subscribe your first 3 points, I do not like the 4th point.
I didn't either. After working on it some more, what I want to do now
is keep the ACL representation the same as it is, but implicitly assume
that the owner has all grant options whether the ACL says so
On Mon, May 17, 2004 at 05:01:36PM +0200, Gaetano Mendola wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruno Wolff III wrote:
| On Sun, May 16, 2004 at 04:36:55 +0200,
| Gaetano Mendola [EMAIL PROTECTED] wrote:
|
|The type is indexable and provide also conversion methods:
|
From: Gaetano Mendola [mailto:[EMAIL PROTECTED]
I think I have to discard also the addresses with last octet
equal to 256.
Any comments ?
Any octet that contains a number less than 0 or greater than 255 should be
suspect.
Assuming you really meant 255:
It would be perfectly legal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Page wrote:
|-Original Message-
|From: Gaetano Mendola [mailto:[EMAIL PROTECTED]
|Sent: 17 May 2004 16:02
|To: Bruno Wolff III
|Cc: [EMAIL PROTECTED]
|Subject: Re: [HACKERS] Email data type
|
|About the domain literals, I think to validate
-Original Message-
From: Steve Atkins [mailto:[EMAIL PROTECTED]
Sent: 17 May 2004 16:46
To: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Email data type
[EMAIL PROTECTED] is syntactically valid. [EMAIL PROTECTED] is
syntactically valid, but should be immediately rejected.
I
On Mon, May 17, 2004 at 05:01:05PM +0100, Dave Page wrote:
[EMAIL PROTECTED] is syntactically valid. [EMAIL PROTECTED] is
syntactically valid, but should be immediately rejected.
I disagree - just because the database server cannot verify the the
existence of a domain does not mean that
-Original Message-
From: Gaetano Mendola [mailto:[EMAIL PROTECTED]
Sent: 17 May 2004 17:02
To: Dave Page
Cc: Bruno Wolff III; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Email data type
Well I think that accept an email like:
[EMAIL PROTECTED]
is a risky.
It's true
On Mon, May 17, 2004 at 09:21:54AM -0700, Steve Crawford wrote:
Along those lines [EMAIL PROTECTED] and [EMAIL PROTECTED] are valid but they
don't necessarily refer to the same mailbox (depends on the mx for
foo.bar.com).
I don't believe the latter is actually valid, as it has to be an
I would tend to put everything in include/postgresql/config:
On second thought, I would hesitate with lib/..., as config file are
plateform specific so they cannot be shared with other plateforms,
although it could be the case for include files that they could be shared.
--
Fabien Coelho -
On Monday 17 May 2004 8:45 am, Steve Atkins wrote:
Also, [EMAIL PROTECTED] is a syntactically valid email address, in the
.13 TLD. It does not deliver to 10.11.12.13, or anywhere else, as
of today, unless the MTA or local recursive resolver is broken (a
common case). [EMAIL PROTECTED] is a
Jan Wieck wrote:
I am still wondering about two things:
Somebody has posted a 2PC patch - I haven't seen too many comments
Somebody has posted sync multimaster replication (PgCluster) - nobody
has commented on that. Maybe I am the only one who has ever tried it ...
Do you really need
Bruce Momjian wrote:
The only downside to removal is that folks without symlinks (I believe
Win32 only) will loose that functionality with nothing to replace it.
However, I think the clarity of removing it is worth it. Also, I think
someone had a special way to do symlinks on Win32 and we should
Hans-Jürgen Schönig wrote:
Marc G. Fournier wrote:
On Mon, 17 May 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
Agreed, but you are a me too, not a huge percentage of our userbase.
How do you know? Have you polled our complete userbase?
Basically, after 6-7 months of development, I want
Jan Wieck wrote:
Marc G. Fournier wrote:
On Sun, 16 May 2004, Bruce Momjian wrote:
I personally don't think Win32 is enough of a new feature either, but
others disagree.
Jan, correct me if I'm wrong ... Jan's point is that we have enough
already to warrant a beta on June 1st, even
Marc G. Fournier wrote:
On Mon, 17 May 2004, Bruce Momjian wrote:
Most hopefully this is very discouraging! Connection pools are a nice
thing and I have used pgpool recently with great success, for pooling
connections. But attempting to deliver multimaster replication as a
byproduct
On Mon, 17 May 2004, Bruce Momjian wrote:
Most hopefully this is very discouraging! Connection pools are a nice
thing and I have used pgpool recently with great success, for pooling
connections. But attempting to deliver multimaster replication as a
byproduct of a connection pool isn't
On Mon, May 17, 2004 at 17:11:42 +0200,
Gaetano Mendola [EMAIL PROTECTED] wrote:
That's true, I will order as Tommi Maekitalo suggest.
And how do domain literals fit into this?
[EMAIL PROTECTED] is a valid email address for me. (At least as
long as my server is at that IP address.)
It's rumoured that Steve Atkins once said:
On Mon, May 17, 2004 at 05:01:05PM +0100, Dave Page wrote:
[EMAIL PROTECTED] is syntactically valid. [EMAIL PROTECTED] is
syntactically valid, but should be immediately rejected.
I disagree - just because the database server cannot verify the the
Manfred Spraul [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Bruce Momjian wrote:
The only downside to removal is that folks without symlinks (I believe
Win32 only) will loose that functionality with nothing to replace it.
However, I think the clarity of removing it is worth it.
Interesting.
We have made COMPLETELY different experiences.
There is one question people ask me daily: When can we have sychronous
replication and PITR?.
Performance is not a problem here. People are more interested in
stability and enterprise features such as those I have mentioned
Thomas Hallgren wrote:
Manfred Spraul [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Bruce Momjian wrote:
The only downside to removal is that folks without symlinks (I believe
Win32 only) will loose that functionality with nothing to replace it.
However, I think the clarity of
Mario Weilguni wrote:
Interesting. We have made COMPLETELY different experiences.
There is one question people ask me daily: When can we have
sychronous replication and PITR?. Performance is not a problem
here. People are more interested in stability and enterprise
features such as those I have
Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
I probably said that wrong, but how do backends get their stats data?
They read it out of a flat file that the stats collector rewrites every
so often.
Ok so that would be easy to do (if we decide we want to)
Is that really
On Mon, 2004-05-17 at 15:10, Bruce Momjian wrote:
It is too late to think about pushing back another month. We had this
discussion already. June 1 is it.
I think I have to reiterate: PITR won't make 1 June. (I will be away
travelling soon). This has been said a number of times.
This is
The only downside to removal is that folks without symlinks
(I believe
Win32 only) will loose that functionality with nothing to
replace it.
However, I think the clarity of removing it is worth it.
Also, I think
someone had a special way to do symlinks on Win32 and we should look
into that.
On Mon, May 17, 2004 at 17:01:36 +0200,
Gaetano Mendola [EMAIL PROTECTED] wrote:
Also the validator will validate emails in this form, if you are thinking to
validate emails as:
Gaetano M. Public(junior)gmendola@(new account)bigfoot.com
That appears to be an rfc 2822 address. RFC 2821
On Mon, May 17, 2004 at 18:01:43 +0200,
Gaetano Mendola [EMAIL PROTECTED] wrote:
Well I think that accept an email like:
[EMAIL PROTECTED]
Be careful about this. [EMAIL PROTECTED] is not the same as
[EMAIL PROTECTED] .
---(end of
Hans-Jürgen Schönig wrote:
Somebody has posted sync multimaster replication (PgCluster) - nobody
has commented on that. Maybe I am the only one who has ever tried it ...
I didn't find it on pgFoundry, others place to look at it ?
Regards
Gaetano Mendola
---(end of
Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 17 May 2004, Bruce Momjian wrote:
Most hopefully this is very discouraging! Connection pools are a nice
thing and I have used pgpool recently with great success, for pooling
connections. But attempting to deliver multimaster replication as
Bruno Wolff III wrote:
On Mon, May 17, 2004 at 18:01:43 +0200,
Gaetano Mendola [EMAIL PROTECTED] wrote:
Well I think that accept an email like:
[EMAIL PROTECTED]
Be careful about this. [EMAIL PROTECTED] is not the same as
[EMAIL PROTECTED]] .
Not wanting to
Simon Riggs wrote:
On Mon, 2004-05-17 at 15:10, Bruce Momjian wrote:
It is too late to think about pushing back another month. We had this
discussion already. June 1 is it.
Just to throw in my .02, plPerlNG won't be ready for testing until mid,
later June either. Then there is also plPHP
Bruce Momjian wrote:
Andrew Dunstan wrote:
I think we should use the relative-path method *unless* the configure
command called out specific installation directories (that is, not
just --prefix but --datadir and/or related options). If you use one of
those then that absolute path should be used
On Mon, 17 May 2004, Joshua D. Drake wrote:
Personally, Win32, subtransactions and PITR are what we are after.
Second would be inclusion of plPHP and plPerlNG which are arguably the
most widely used languages to connect to PostgreSQL.
plPHP and plPerlNG both belong on pgfoundry, not in the
Mario Weilguni wrote:
Interesting.
We have made COMPLETELY different experiences.
There is one question people ask me daily: When can we have sychronous
replication and PITR?.
Performance is not a problem here. People are more interested in
stability and enterprise features such as those I have
plPHP and plPerlNG both belong on pgfoundry, not in the core distribution
...
Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to
replace plPerl, I was talking with Bruce and he seemed to think that (as
long as the code was good enough) that we could incorporate plPHP???
Mario Weilguni wrote:
Interesting.
We have made COMPLETELY different experiences.
There is one question people ask me daily: When can we have sychronous
replication and PITR?.
Performance is not a problem here. People are more interested in
stability and enterprise features such as those I have
Tommi Maekitalo [EMAIL PROTECTED] writes:
Sorting should then be done by top-level-domain first. Then 2nd, 3rd... and
last by user.
I thought of that but decided not to suggest it:
a) as far as email goes there's no relationship between [EMAIL PROTECTED] and
[EMAIL PROTECTED] The .com
Marko Karppinen [EMAIL PROTECTED] writes:
On 17. touko 2004, at 10:40, Tatsuo Ishii wrote:
Consider a program using JDBC on localhost. It can only reach to
PostgreSQL via TCP/IP.
Huh? Why on earth would that be true? Is this a limitation of our JDBC
drivers?
Ah! Of course. That makes
Simon Riggs [EMAIL PROTECTED] writes:
I can't complete by 1 June. Think worse of me if you choose.
I'll mention another perspective as a user. I'm actually happier seeing a
relatively minor release come out just before the big changes hit. If 7.5 has
Windows, PITR, nested transactions, etc.
Greg Stark [EMAIL PROTECTED] writes:
Doug McNaught [EMAIL PROTECTED] writes:
Java doesn't support Unix domain sockets. If you want to use JDBC,
you have to use TCP sockets.
That doesn't follow. That just means you can't implement a unix domain socket
driver using only Java. Is there some
Doug McNaught [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Marko Karppinen [EMAIL PROTECTED] writes:
On 17. touko 2004, at 10:40, Tatsuo Ishii wrote:
Consider a program using JDBC on localhost. It can only reach to
PostgreSQL via TCP/IP.
Huh? Why on earth
Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I can't complete by 1 June. Think worse of me if you choose.
...
So in my perfect world I picture 7.5 freezing June 1 and releasing in July or
so, giving a nice reliable simple upgrade for people who just want a safe 7.x
series to upgrade to
On Mon, 17 May 2004, Joshua D. Drake wrote:
plPHP and plPerlNG both belong on pgfoundry, not in the core distribution
...
Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to
replace plPerl, I was talking with Bruce and he seemed to think that (as
long as the code was
Magnus Hagander wrote:
If you run NTFS, it's still possible to use arbitrary links.
In the Windows
world, they are called junctions. Microsoft does not provide
a junction tool
for some reason (perhaps because it's limited to NTFS). A
good tool, free
and with source, can be found here
Jan Wieck wrote:
I think if we go for the plan outlined, we will not need a special
configure flag. (People might decide to move the install dir long after
they install it.) By default, everything sits under pgsql as pgsql/bin,
pgsql/lib, etc. I can't see how making it relative is going
Mike Mascari [EMAIL PROTECTED] writes:
Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I can't complete by 1 June. Think worse of me if you choose.
...
So in my perfect world I picture 7.5 freezing June 1 and releasing in July or
so, giving a nice reliable simple upgrade for
On Mon, 17 May 2004, Mike Mascari wrote:
Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I can't complete by 1 June. Think worse of me if you choose.
...
So in my perfect world I picture 7.5 freezing June 1 and releasing in July or
so, giving a nice reliable simple upgrade
Marc G. Fournier wrote:
On Mon, 17 May 2004, Joshua D. Drake wrote:
Personally, Win32, subtransactions and PITR are what we are after.
Second would be inclusion of plPHP and plPerlNG which are arguably the
most widely used languages to connect to PostgreSQL.
plPHP and plPerlNG both belong on
Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 17 May 2004, Bruce Momjian wrote:
Most hopefully this is very discouraging! Connection pools are a nice
thing and I have used pgpool recently with great success, for pooling
connections. But attempting to deliver multimaster
Marc G. Fournier wrote:
On Mon, 17 May 2004, Joshua D. Drake wrote:
plPHP and plPerlNG both belong on pgfoundry, not in the core distribution
...
Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to
replace plPerl, I was talking with Bruce and he seemed to think that (as
long
The much I am for pulling stuff that does not belong into core, doing
it just for the fun of cleaning up or trimming doesn't do. One of the
major functions of CVS is that one can tag collections of revisions
that together build a release, a known to be working snapshot of file
revisions. If
Joshua D. Drake wrote:
Just to throw in my .02, plPerlNG won't be ready for testing until mid,
later June either. Then there is also plPHP which although we haven't
had any bug reports still needs some more peer review.
Also we would like to submit our ECPG which includes SET DESCRIPTOR
He is waiting for nested transactions to be committed so he can merge
his work in.
Somebody has posted sync multimaster replication (PgCluster) - nobody
has commented on that. Maybe I am the only one who has ever tried it ...
I think it should be on gborg.
You mean pgFoundry :)
Chris
Alternative database location:
Should this code be removed now?
I think that this:
CREATE DATABASE blah LOCATION 'xyz';
Should now be interpreted to mean:
CREATE TABLESPACE blah_tbsp LOCATION 'xyz';
CREATE DATABSE blah TABLESPACE blah_tbsp;
Or something like that...
Chris
Marc G. Fournier wrote:
On Mon, 17 May 2004, Joshua D. Drake wrote:
plPHP and plPerlNG both belong on pgfoundry, not in the core distribution
...
Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to
replace plPerl, I was talking with Bruce and he seemed to
I assume your ecpg will be a patch to the existing ecpg rather than a
new verion, right?
Yes it is a patch against 7.4.2
J
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
On Mon, 17 May 2004, Bruce Momjian wrote:
Server-side languages are tied into the backend even closer than the
user data types. They are best in the core distribution. We didn't put
plR in core because it had a conflicting license.
So, they can live on their own, which is a good thing to
On Mon, 17 May 2004, Jan Wieck wrote:
They are not as independant as one might think. The core support for set
returning functions is required before a PL can do it. Same was with
cursors and same will be with subtransactions being the base for
exception handling. People have been struggling
Marc G. Fournier wrote:
On Mon, 17 May 2004, Mike Mascari wrote:
A quick google of 7.4 Win32 release will reveal that the above was
precisely what was said about 7.4: it would be released to not hold
up important features like the IN optimization and a quick 7.5 would
have Win32 and PITR. It's
On Mon, 17 May 2004, Joshua D. Drake wrote:
I assume your ecpg will be a patch to the existing ecpg rather than a
new verion, right?
Yes it is a patch against 7.4.2
Will you have one against -HEAD? I believe there have been changes since
7.5 was branched, no? Or have they been
Why is it our responsibility to ensure that though? Shouldn't the
developer (or group of developers) responsible for the
PL/interface/extension be responsible for that?
Let's use plPHP as an example here ... I'm going to guess that it supports
PHP4, which is the 'standard' right now ... what
Marc G. Fournier wrote:
On Mon, 17 May 2004, Joshua D. Drake wrote:
I assume your ecpg will be a patch to the existing ecpg rather than a
new verion, right?
Yes it is a patch against 7.4.2
Will you have one against -HEAD? I believe there have been changes since
7.5 was
Bruce Momjian said:
Marc G. Fournier wrote:
On Mon, 17 May 2004, Joshua D. Drake wrote:
plPHP and plPerlNG both belong on pgfoundry, not in the core
distribution ...
Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed
to replace plPerl, I was talking with Bruce
On Mon, May 17, 2004 at 18:00:48 -0400,
Andrew Dunstan [EMAIL PROTECTED] wrote:
But what we listen to relates to the destination address of the packets,
not the source address ...
There still is some small risk. If you OS doesn't reject packets destined
for 127.*.*.* that don't come from
Marc G. Fournier wrote:
A quick google of 7.4 Win32 release will reveal that the above was
precisely what was said about 7.4: it would be released to not hold
up important features like the IN optimization and a quick 7.5 would
have Win32 and PITR. It's almost as if a cron job reposts this
On Mon, May 17, 2004 at 17:06:18 -0400,
Greg Stark [EMAIL PROTECTED] wrote:
I'll mention another perspective as a user. I'm actually happier seeing a
relatively minor release come out just before the big changes hit. If 7.5 has
Windows, PITR, nested transactions, etc. especially if I see
So, yea, I am frustrated. I know these features are hard and complex,
but I want them for PostgreSQL, and I want them as soon as possible. I
guess what really bugs me is that we are so close to having these few
remaining big features, and because they are so complex, they are taking
a lot
Bruno Wolff III said:
On Mon, May 17, 2004 at 18:00:48 -0400,
Andrew Dunstan [EMAIL PROTECTED] wrote:
But what we listen to relates to the destination address of the
packets, not the source address ...
There still is some small risk. If you OS doesn't reject packets
destined for
On Mon, 17 May 2004, Joshua D. Drake wrote:
So, yea, I am frustrated. I know these features are hard and complex,
but I want them for PostgreSQL, and I want them as soon as possible. I
guess what really bugs me is that we are so close to having these few
remaining big features, and because
On Mon, May 17, 2004 at 04:55:50PM +0200, Zeugswetter Andreas SB SD wrote:
It is too late to think about pushing back another month. We had this
discussion already. June 1 is it.
I thought the outcome of that discussion was June 15 ?
I think there was no outcome. There was no official
Greetings all,
We have noticed a way to make a major improvement in Pg's performance on
our workload, and I would like to get your thoughts before I go off to
work up a patch.
The basic problem is that Pg seeks far too much when performing an index
scan. I have saved an strace of a backend
Alvaro Herrera Munoz wrote:
Personally I've been focused on getting subtransactions done and now I think
I'm very close to an acceptable patch, but what has slowed me down the last
time has been lack of feedback from core developers. It was feedback I
needed to figure out the best ways to do
Yes, fetching a RID list from an index scan, sorting 'em and then
fetching from the table would be a very appreciable speedup for many
queries. I would imagine that all the commercial engines do this (db2
calls it a sorted RID-list-fetch) .. and this has in fact been
discussed on -hackers before.
I'll be away from PostgreSQL development from approximately the end of
May until August 20th. I won't be subscribed to any PG-related mailing
lists for that period. However, I'll still be accessible via email to
this address.
Have a great summer, everyone.
-Neil
---(end
1 - 100 of 105 matches
Mail list logo
