Bruce Momjian wrote:
Sounds interesting, but I am not sure how that is going to track
multiple versions of the patch,
They could easily be submitted through the web interface as revisions to
the original version.
or changes in the email subject.
We'd need to keep the reference number in
Tom Lane wrote:
Henry B. Hotz [EMAIL PROTECTED] writes:
Don't you want to maintain some interoperability between 8.2 client/
server and 8.3 server/client at least?
Hm, you mean that what you called a C API change actually
break^H^H^H^H^Hchanges the on-the-wire protocol as well?
That
Henry B. Hotz wrote:
OK, so posted. ;-)
snip
Would you like a new version of the patch with the incomplete
functionality commented out (or otherwise removed)?
Yes please :-) I was going to try to do one of those myself, but since
you already know your way around the code, please do it. And
Hi,
I want to add a column in the table and also want to hidde that column from
the user. So that user's normal insertion and update goes on (means user
will not supply the value for my hidden column). Is there any way to hidde
the column from the user. I tried to make my column (attisdropped
rupesh bajaj wrote:
Hi,
I want to add a column in the table and also want to hidde that column from
the user. So that user's normal insertion and update goes on (means user
will not supply the value for my hidden column). Is there any way to hidde
the column from the user. I tried to make my
On Tue, May 01, 2007 at 03:09:17PM +0530, rupesh bajaj wrote:
Hi,
I want to add a column in the table and also want to hidde that column from
the user. So that user's normal insertion and update goes on (means user
will not supply the value for my hidden column). Is there any way to hidde
the
On Tue, 1 May 2007, rupesh bajaj wrote:
Hi,
I want to add a column in the table and also want to hidde that column from
the user. So that user's normal insertion and update goes on (means user
will not supply the value for my hidden column). Is there any way to hidde
the column from the user. I
Any suggestions? pgdiagnostics?
I'm happy with forensics myself.
Bruce Momjian wrote:
Sounds good, though I am worried that forensics will not be a word
easily understood by non-native English speakers.
---
Heikki
thankyou very much.
but the method, you said, is adding a alias name, so it can not work.
and as i need to add many functions likes this, so the best way is to
compile the whole postgresql. eventhough, i did, it didnot work, so i am
puzzled, can add a function directly in the source file, and
Dave Page wrote:
The bottom line is that there is a lot of thinking that the patch queue
is so large because no one knows what to do. Oh, if we were better
communicators, more would be done. The patch queue is large because we
have lots of March 31 patches, and because we don't have
Heikki Linnakangas wrote:
Any suggestions? pgdiagnostics?
Yes, I like diagnostics, or internals. I just think forensics isn't
going to be understood by the average native English speaker, let alone
non-English speakers.
Naz Gassiep wrote:
I believe the suggestion was to have an automated process that only ran
on known, sane patches.
How do we know in advance of reviewing them that they are sane?
What is more, we often run into situations where patch a will require
changes in patch b, so testing them
On Tue, 2007-01-05 at 02:54 +0100, Gregory Stark wrote:
Naz Gassiep [EMAIL PROTECTED] writes:
Even if the patch inventory wasn't kept right up to date, this system
could potentially help many regression issues or bugs to surface sooner,
I just don't understand what this would accomplish.
Bruce Momjian wrote:
The bottom line is if you had a system that was 100% perfect in
capturing all information about a patch, it only helps us 2% toward
reviewing the patch, and what is the cost of keeping 100% information?
2% for you or Tom reviewing a recently discussed, run-of-the mill
I just realized that there's a problem with the patch I applied here
http://archives.postgresql.org/pgsql-committers/2007-03/msg00057.php
to ensure that the result type of an inline'd SQL function is correctly
marked in the resulting expression tree. To wit, it doesn't work for
functions
Bruce Momjian [EMAIL PROTECTED] writes:
Heikki Linnakangas wrote:
Any suggestions? pgdiagnostics?
Yes, I like diagnostics, or internals. I just think forensics isn't
going to be understood by the average native English speaker, let alone
non-English speakers.
diagnostics is a two-dollar
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Heikki Linnakangas wrote:
Any suggestions? pgdiagnostics?
Yes, I like diagnostics, or internals. I just think forensics isn't
going to be understood by the average native English speaker, let alone
non-English speakers.
diagnostics
Bruce,
The bottom line is if you had a system that was 100% perfect in
capturing all information about a patch, it only helps us 2% toward
reviewing the patch, and what is the cost of keeping 100% information?
2% for you or Tom reviewing a recently discussed, run-of-the mill patch.
I
On Apr 28, 2007, at 8:00 PM, David Fetter wrote:
Here's an SQL version without much in the way of bounds checking :)
CREATE OR REPLACE FUNCTION generate_series (
start_ts timestamptz,
end_ts timestamptz,
step interval
) RETURNS SETOF timestamptz
LANGUAGE sql
AS $$
SELECT
CASE
Two more ideas for the manager, now that we seem to have consensus to
build one.
On Apr 30, 2007, at 6:04 PM, Josh Berkus wrote:
-- We could save the patches by applied date and index them, and
then have a
place to point users when they ask: When was X fixed? Do I *have* to
upgrade to 8.1
Heikki Linnakangas wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Heikki Linnakangas wrote:
Any suggestions? pgdiagnostics?
Yes, I like diagnostics, or internals. I just think forensics isn't
going to be understood by the average native English speaker, let alone
Josh,
Josh Berkus wrote:
Is there a reason why the system needs to be primarily based on e-mail? I was
thinking that the patch manager would be entirely a web tool, with people
submitting and modifying a patch directly through a web interface. This
would be lots easier to build than an
Dave,
The reason for basing the system on email is simply that it minimises
the changes required in the community process. If it were entirely web
based, we'd have to change the way we all work to discuss patches in a
forum style, rather than a list style. I have a sneaking suspicion that
at
Zdenek Kotala wrote:
I did not find forensics in translator and It mentions in Oxford
vocabulary but explanation is not clear for me. I agree with Bruce It is
not good name. What about short form of diagnostic diag?
Doesn't forensics basically mean to find the cause of something
*after* it
On Tue, 2007-05-01 at 09:43 -0700, Josh Berkus wrote:
The current patch-queue process is failing to scale with the project: every
release it gets to be more work for you Tom to integrate the patches. We
need to think of new approaches to make the review process scale. As a
pointed
On May 1, 2007, at 1:16 AM, Magnus Hagander wrote:
Henry B. Hotz wrote:
OK, so posted. ;-)
snip
Would you like a new version of the patch with the incomplete
functionality commented out (or otherwise removed)?
Yes please :-) I was going to try to do one of those myself, but since
you
Florian G. Pflug [EMAIL PROTECTED] writes:
Doesn't forensics basically mean to find the cause of something
*after* it happened, based on traces that the event left behind?
Hmm ... the Oxford English Dictionary defines forensic as pertaining
to, connected with, or used in courts of law. There
I wrote:
I think the correct thing is to do nothing, and assume the expanded
expression must have the right type already, if the function is declared
to return a pseudotype. The only pseudotypes allowed as SQL-function
results are RECORD, VOID, and polymorphic, and this seems OK and maybe
Zdenek Kotala wrote:
Heikki Linnakangas wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Heikki Linnakangas wrote:
Any suggestions? pgdiagnostics?
Yes, I like diagnostics, or internals. I just think forensics
isn't
going to be understood by the average native English
Magnus,
I'd also vote for changing the name of the non encrypted version to
just gss instead of gss-np.
I don't. We'll want to support GSS encryption once we have the code, so we
should leave the namespace open to address that.
Oh, and I do think putting in GSSAPI authentication only (and
Henry B. Hotz wrote:
On May 1, 2007, at 1:16 AM, Magnus Hagander wrote:
Henry B. Hotz wrote:
Would you like a new version of the patch with the incomplete
functionality commented out (or otherwise removed)?
Yes please :-) I was going to try to do one of those myself, but since
you
Josh Berkus wrote:
Magnus,
I'd also vote for changing the name of the non encrypted version to
just gss instead of gss-np.
I don't. We'll want to support GSS encryption once we have the code, so we
should leave the namespace open to address that.
I agree that we should do this, I'm
Josh Berkus wrote:
If many people are going to block on using a web tool for submitting new
versions of a patch, claiming responsibility for review, etc., though, then
we should probably abandon this discussion right here. No new tool is going
to work if we have people who won't make any
Josh Berkus wrote:
Magnus,
I'd also vote for changing the name of the non encrypted version to
just gss instead of gss-np.
I don't. We'll want to support GSS encryption once we have the code, so we
should leave the namespace open to address that.
Oh, and I do think putting in GSSAPI
Andrew Dunstan wrote:
Now that we seem to have MSVC building working tolerably well, I think
we need a bit of cleanup. In particular, I think the config setup needs
to be more like the arguments we pass to the standard configure script.
Why?
I'm not saying I'm against it, I'd just like to
Josh Berkus wrote:
Dave,
The reason for basing the system on email is simply that it minimises
the changes required in the community process. If it were entirely web
based, we'd have to change the way we all work to discuss patches in a
forum style, rather than a list style. I have a
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Josh Berkus wrote:
For now, yes. In the long run, we want to provide users with other methods
of encrypted connections than the rather flaky and
not-available-on-every-platform OpenSSL.
I'm curious - on what platform is OpenSSL NOT available
Andrew,
So if the commercial
backers of PostgreSQL want better management of the project, maybe they
need to find some resources to help out.
I don't think they really care, or we'd have heard something by now. I
think this is up to us PG developers.
--
--Josh
Josh Berkus
PostgreSQL @
Magnus Hagander [EMAIL PROTECTED] writes:
I would call them gss and gss-sec. Or possibly gss-enc. I think
that's a lot more clear than gss-np (something ending with -sec is a
giveaway)
+1
regards, tom lane
---(end of
Magnus Hagander wrote:
Andrew Dunstan wrote:
Now that we seem to have MSVC building working tolerably well, I think
we need a bit of cleanup. In particular, I think the config setup needs
to be more like the arguments we pass to the standard configure script.
Why?
I'm not saying I'm
Andrew Dunstan wrote:
Why?
I'm not saying I'm against it, I'd just like to know why? Personally, I
find the store-in-a-file a whole lot more handy.
I am only talking about the names. I want the hash key names to be the
same as the configure argument names.
Oh, misunderstood you there.
Josh Berkus wrote:
Andrew,
So if the commercial
backers of PostgreSQL want better management of the project, maybe they
need to find some resources to help out.
I don't think they really care, or we'd have heard something by now. I
think this is up to us PG developers.
--- Original Message ---
From: Andrew Dunstan [EMAIL PROTECTED]
To: Josh Berkus [EMAIL PROTECTED]
Sent: 01/05/07, 21:10:07
Subject: Re: [HACKERS] Feature freeze progress report
So if the commercial
backers of PostgreSQL want better management of the project, maybe they
need
Jim Nasby [EMAIL PROTECTED] writes:
Are you sure the case statements are needed? It seems it would be
better to just punt to the behavior of generate_series (esp. if
generate_series eventually learns how to count backwards).
What's this eventually?
regression=# select * from
I notice that we have two versions of not INHERITing:
ALTER ROLE meek NOINHERIT earth;
ALTER TABLE meek NO INHERIT earth;
Is there some merit in deciding on just one of these syntaxes? It seems
like we will have to support both the above, but we should encourage
just one common way, just for
Tom,
And even more curious to see you defend that offhanded bashing of
OpenSSL, a tool a whole lot of people (including me) depend on all day
every day. If Postgres had the market penetration of OpenSSL, our lives
would be a lot different. Have you got even a shred of evidence that
GSSAPI
On May 1, 2007, at 1:33 PM, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I would call them gss and gss-sec. Or possibly gss-enc. I think
that's a lot more clear than gss-np (something ending with -sec
is a
giveaway)
+1
If we settle on gss-np and gss-sec is that a good
Josh Berkus wrote:
Tom,
And even more curious to see you defend that offhanded bashing of
OpenSSL, a tool a whole lot of people (including me) depend on all day
every day. If Postgres had the market penetration of OpenSSL, our lives
would be a lot different. Have you got even a shred of
Simon Riggs [EMAIL PROTECTED] writes:
I notice that we have two versions of not INHERITing:
ALTER ROLE meek NOINHERIT earth;
ALTER TABLE meek NO INHERIT earth;
Where are you reading that?
regards, tom lane
---(end of
Henry B. Hotz wrote:
On May 1, 2007, at 1:33 PM, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I would call them gss and gss-sec. Or possibly gss-enc. I think
that's a lot more clear than gss-np (something ending with -sec is a
giveaway)
+1
If we settle on gss-np and
On May 1, 2007, at 2:30 PM, Magnus Hagander wrote:
Henry B. Hotz wrote:
On May 1, 2007, at 1:33 PM, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I would call them gss and gss-sec. Or possibly gss-enc. I
think
that's a lot more clear than gss-np (something ending with -
sec
Henry B. Hotz wrote:
I would call them gss and gss-sec. Or possibly gss-enc. I think
that's a lot more clear than gss-np (something ending with -sec is a
giveaway)
+1
If we settle on gss-np and gss-sec is that a good compromise?
I still think the -np part is unclear - it's not easily
On May 1, 2007, at 1:32 PM, Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Josh Berkus wrote:
For now, yes. In the long run, we want to provide users with
other methods
of encrypted connections than the rather flaky and
not-available-on-every-platform OpenSSL.
I'm
Josh Berkus [EMAIL PROTECTED] writes:
Long Answer:
I've been dealing with OpenSSL binary incompatibility issues for the last
few Solaris builds and it's made me very unhappy with the
upgrade/versioning/linking of OpenSSL, and explained a lot of issues I've
had around using OpenSSL with
Short answer:
Existing Kerberos libs with GSSAPI may have the same issues; I don't know.
What I was speaking in favor of was having several encryption mechanisms
available so that at least one of them would be available on the user's
system at installation time. For that matter, I think we
Simon Riggs [EMAIL PROTECTED] writes:
(Yes, I understand the word means totally different thing in each case).
Geez, you had me worried. So it's just the spelling that you're noting?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of
Henry B. Hotz [EMAIL PROTECTED] writes:
Windows? I don't do Windows, so I'm guessing.
If you accept that Microsoft's SSPI is a flavor of GSSAPI, then
GSSAPI is more widely supported and probably more stable on Windows
machines than OpenSSL is.
I can't speak to the situation on Windows
On Tue, 2007-05-01 at 17:30 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I notice that we have two versions of not INHERITing:
ALTER ROLE meek NOINHERIT earth;
ALTER TABLE meek NO INHERIT earth;
Where are you reading that?
Ale Raza wrote:
Simon,
I am forwarding this to pgsql-hackers. I can send the requirements once
I get the right contact.
This is it, but as Simon stated, you probably want to get the PostGIS
guys involved too, so that duplicates can be sorted out.
--
Alvaro Herrera
Tom, Josh, Magnus.
I can't speak to the situation on Windows either; if OpenSSL isn't
commonly used on Windows that may be a sufficient reason for supporting
GSSAPI too. I'm just unconvinced by any argument that suggests we'll
replace our SSL support with it.
I can't imagine we will either.
On Tue, May 01, 2007 at 05:08:45PM -0400, Tom Lane wrote:
Jim Nasby [EMAIL PROTECTED] writes:
Are you sure the case statements are needed? It seems it would be
better to just punt to the behavior of generate_series (esp. if
generate_series eventually learns how to count backwards).
Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.
How long ago did you check? I've been using OpenSSL on windows for many
years. Actually, it was supported just fine on Windows back when it was
added to PostgreSQL *at least*.
I didn't say *available for
On Tue, 2007-05-01 at 22:36 +0100, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
(Yes, I understand the word means totally different thing in each case).
Geez, you had me worried. So it's just the spelling that you're noting?
Yes, the space appears to be mis spelled.
--
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2007-05-01 at 17:30 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I notice that we have two versions of not INHERITing:
ALTER ROLE meek NOINHERIT earth;
ALTER TABLE meek NO INHERIT earth;
Where are you reading that?
Andrew Dunstan wrote:
Josh Berkus wrote:
Andrew,
So if the commercial
backers of PostgreSQL want better management of the project, maybe they
need to find some resources to help out.
I don't think they really care, or we'd have heard something by now. I
think
On May 1, 2007, at 3:11 PM, Magnus Hagander wrote:
Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.
How long ago did you check? I've been using OpenSSL on windows
for many
years. Actually, it was supported just fine on Windows back when
it was
added to
For all that Tom reserved 100 numbers for us, we're only using one right
now.
lwgeom_estimate.c:47:#define STATISTIC_KIND_GEOMETRY 100
Paul
Alvaro Herrera wrote:
Ale Raza wrote:
Simon,
I am forwarding this to pgsql-hackers. I can send the requirements once
I get the right contact.
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Jim Nasby) wrote:
Two more ideas for the manager, now that we seem to have consensus to
build one.
One other thing a webapp would allow that would help grow the community.
If the patches are all in a public place then reviewer wannabees
ITAGAKI Takahiro wrote:
I wrote:
I found that autovacuum launcher does not launch any workers in HEAD.
The attached autovacuum-fix.patch could fix the problem. I changed
to use 'greater or equal' instead of 'greater' at the decision of
next autovacuum target.
I developed a different fix,
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, Tom, Heikki, I need one of you to post the list of patches and
where we think we are on each one, even if the list is imperfect.
This message is an attempt to sort out which patch queue entries have
no hope of getting into 8.3 (and so we shouldn't
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Oh, another thing that I think may be happening is that the stack is
restored in longjmp, so it is trying to report an error elsewhere but
it crashes because something got overwritten or something; i.e. a
bug in the error recovery
On Tue, 1 May 2007, Tom Lane wrote:
* Re: [PATCHES] Synchronized Scan WIP patch
/Simon Riggs/
Heikki is reviewing this one. Also I believe Greg Smith is doing more
performance testing.
Actually it was the Automatic adjustment of bgwriter_lru_maxpages patch
from Itagaki Takahiro I've
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm wondering if it wouldn't be more robust to define a longjmp target
block before calling BaseInit(), and have it exit cleanly in case of
failure (which is what you say elog.c should be doing if there is no
target block).
No, because elog is already
Greg Smith [EMAIL PROTECTED] writes:
On Tue, 1 May 2007, Tom Lane wrote:
* Re: [PATCHES] Synchronized Scan WIP patch
/Simon Riggs/
Heikki is reviewing this one. Also I believe Greg Smith is doing more
performance testing.
Actually it was the Automatic adjustment of bgwriter_lru_maxpages
I wrote:
Hmm ... I was about to say that the postmaster never sets
PG_exception_stack, but maybe an error out of a PG_TRY/PG_RE_THROW
could do it? Does the postmaster ever execute PG_TRY?
Doh, I bet that's it, and it's not the postmaster that's at issue
but PG_TRY blocks executed during
Andrew Dunstan wrote:
Naz Gassiep wrote:
I believe the suggestion was to have an automated process that only ran
on known, sane patches.
How do we know in advance of reviewing them that they are sane?
Same way as happens now. I would assume this mechanism would only be
applied to patches that
Bruce,
As an example, how is patch information going to help us review HOT or
group-item-index? There is frankly more information about these in the
archives than someone could reasonable read. What someone needs is a
summary of where we are now on the patches, and lots of time.
The idea
Naz Gassiep [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
How do we know in advance of reviewing them that they are sane?
Same way as happens now. I would assume this mechanism would only be
applied to patches that had already been approved to contrib, or some
other measure that can be
Josh Berkus [EMAIL PROTECTED] writes:
Actually, that can happen with the current system. The real blocker there is
that some people, particularly Tom, work so fast that there's no chance for a
new reviewer to tackle the easy stuff. Maybe the real solution is to
encourage some of our other
What is approved to contrib?
The problem here is that having reasonable certainty that a patch is
not malicious requires having gone over it in some detail; at which
point you might as well apply the thing. Or if you didn't apply it,
you bounced it for reasons that are unlikely to have
On 5/2/07, Tom Lane [EMAIL PROTECTED] wrote:
* [pgsql-patches] Ctid chain following enhancement
/Pavan Deolasee/
I'm not very excited about this --- it seems to me to complicate the code
in some places that are not in fact performance-critical. While it
doesn't seem likely to break
81 matches
Mail list logo