> > feature of that type. But random misfeatures such as the join syntax or
> > the decode() function are going to have a hard time getting accepted.
>
> But we have decode():
>
> test=> \df decode
> List of functions
>Result data type | Schema | Nam
In include/c.h, MemSet() is defined to be different than the stock
function memset() only when copying less than or equal to
MEMSET_LOOP_LIMIT bytes (currently 64). The comments above the macro
definition note:
* We got the 64 number by testing this against the stock memset() on
* BSD
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Rod Taylor wrote:
>> The above, or something along those lines, would show order
>> independence.
> It is this kind of added abstraction that I definitely want to avoid.
I agree. We want to promote the LIMIT/FOR UPDATE ordering, not treat
them on an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Neil Conway wrote:
| [ Sorry, never saw the original email ]
Because it is still hanging in moderation queue ;)
| FYI, we prefer patches in context diff format (diff -c). Also, there
| are some code style rules that most of the backend code follows.
Rod Taylor wrote:
>
> > Yes, I thought about that. People want to show both SELECT syntaxes,
> > but how would you do that --- show the SELECT syntax twice with just
> > those last two clauses reversed --- yuck.
>
> select [ , ... ]
>
> :
>[ FOR UPDATE | LIMIT ]
>
>
> The above, or
[ Sorry, never saw the original email ]
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Jukka Holappa wrote:
> > I'm very new to this project and inspired by recent security
> > release, I started to audit postgresql source against common
> > mistakes with sprintf().
If you're interested, another co
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I seem to have recovered from my Postgres probs. I decided to do a vacuum
> full to clean things up. I got this about halfway through:
> usa=# vacuum full analyze;
> ERROR: No one parent tuple was found
> Any fix for that?
Try a "SELECT
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> Hmm. I did give it a harder look and look what jumped out. Both
> chkpass_out and chkpass_rout return PG_RETURN_CSTRING but chkpass_out
> builds a standard c string while chkpass_rout builds a variable text
> structure. That can't be right.
It's
OK,
I seem to have recovered from my Postgres probs. I decided to do a vacuum
full to clean things up. I got this about halfway through:
usa=# vacuum full analyze;
ERROR: No one parent tuple was found
Log:
2002-08-28 19:38:47 DEBUG: Index expiry_users_users_key: Pages 110; Tuples
41310: De
On August 28, 2002 09:23 am, Tom Lane wrote:
> The behavior looks a lot like a memory clobber, so perhaps the key
> variable is some difference in malloc's allocation strategy, causing
> two items to be adjacent in NetBSD where they are not on the other
> platforms we've tried.
Here's some other
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> After a crash and several restarts this morning, my postgres 7.2.1 is
> running very oddly.
> The processes are hanging in semwait or sbwait or biord states, but mostly
> sbwait.
Some random poking around in google says that sbwait state is
> Yes, I thought about that. People want to show both SELECT syntaxes,
> but how would you do that --- show the SELECT syntax twice with just
> those last two clauses reversed --- yuck.
select [ , ... ]
:
[ FOR UPDATE | LIMIT ]
The above, or something along those lines, would show o
On Wed, 2002-08-28 at 21:29, Robert Treat wrote:
>
> I think after the LIMIT and FOR UPDATE explanations (but before the note about
> SELECT privilege) you could add a note that "for backwards compatibility
> reasons the LIMIT and FOR UPDATE clauses are interchangeable" though maybe
> interch
On Wednesday 28 August 2002 09:14 pm, Bruce Momjian wrote:
> Tom Lane wrote:
> > Perhaps we could compromise on showing only the new syntax in the
> > part of the man page, and then mentioning somewhere in the
> > body of the page that the other order is deprecated but accepted for
> > backwards
Hi guys,
After a crash and several restarts this morning, my postgres 7.2.1 is
running very oddly.
Every time you execute a query it basially takes forever. Some of them
actually do take forever. eg: "select * from users" just hangs forever. As
people use the site all available postgres slots
Tom Lane: "And with the availability of schemas in 7.3, I think that
multiple databases per installation is going to become less common to
begin with --- people will more often use multiple schemas in one big
database if they want the option of data sharing, or completely
separate installations if
Joe Conway <[EMAIL PROTECTED]> writes:
> Is it OK to use fcinfo->flinfo->fn_mcxt as the long term memory
> context or is there a better choice?
That is the correct choice.
> Is funcctx->multi_call_memory_ctx a
> suitable name in place of funcctx->fmctx?
No objection here.
Tom Lane wrote:
> I thought about that and didn't like it; it may simplify the simple case
> but I think it actively gets in the way of less-simple cases. For
> example, the FIRSTCALL code might generate some transient structures
> along with ones that it wants to keep. Also, your recommended
>
Joe Conway <[EMAIL PROTECTED]> writes:
> Maybe SRF_FIRSTCALL_INIT()(init_MultiFuncCall()) should:
> - save CurrentMemoryContext to funcctx->per_call_memory_ctx
>(new member of the struct)
> - save fcinfo->flinfo->fn_mcxt to funcctx->multi_call_memory_ctx
>(nee funcctx->fmctx)
> - leave fci
Tom Lane wrote:
> I think we should document that any memory that is allocated in the
> first call for use in subsequent calls must come from the memory context
> saved in FuncCallContext (and let's choose a more meaningful name than
> fmctx, please). This would mean adding code like
>
> o
Yes, I have recieved it. I assume it is bacause a virus is picking our
email address from a mailbox as the "From:" and sending the virus to
others.
---
Tatsuo Ishii wrote:
> Sorry for the off-topic article, but I wonder a
It will, if a patch is supplied. Anything significant that is mentioned
in the CVS logs gets shown in the release notes.
---
Matthew T. O'Connor wrote:
> > > > Anyone want to argue that we should keep the v0 protocol suppo
Tom Lane wrote:
> >> If you would like a vote, we can do that, but as I remember we had the
> >> same issue with COPY and we got most votes to just show the best syntax.
>
> Perhaps we could compromise on showing only the new syntax in the
> part of the man page, and then mentioning somewhere in
Sorry for the off-topic article, but I wonder anyone has been received
this kind of mail...
I have been received following from [EMAIL PROTECTED] Is this
mail really posted by [EMAIL PROTECTED]? If so, could someone
on postgresql.org stop this kind of alert mail? I'm tired of these
kind of mails.
> > > Anyone want to argue that we should keep the v0 protocol support any
> > > longer?
> >
> > Nope, exactly the same thought crossed my mind while I was reading
> > through the code...
>
> Feel free to rip it out.
Should probably be mentioned in the release notes.
-
>> If you would like a vote, we can do that, but as I remember we had the
>> same issue with COPY and we got most votes to just show the best syntax.
Perhaps we could compromise on showing only the new syntax in the
part of the man page, and then mentioning somewhere in the body of the
page that
On Wednesday 28 August 2002 05:06 pm, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> > > That SELECT syntax is already too confusing. I don't want to add an
> > > additional documentation specification that provides no value to users.
> >
> > The value of the documenta
I've been looking at the sample SRFs (show_all_settings etc) and am not
happy about the way memory management is done. As the code is currently
set up, the functions essentially assume that they are executed in a
context that will never be reset until they're done returning tuples.
(This is true
Bruce Momjian wrote:
> With beta starting September 1, what time table do we want to have? Is
> feature freeze September 1? When do we want to package up the beta1
> tarball?
>
> I will try to have the HISTORY/release.sgml file ready for September 1.
>
Since September 1 is a Sunday, how about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
| I have reviewed your patch, and it is a thorough job. Unfortunately,
| our code has drifted dramatically since 7.2 in the areas you patched.
| Would you be able to download our CVS or current snapshot and submit a
| patch based
With beta starting September 1, what time table do we want to have? Is
feature freeze September 1? When do we want to package up the beta1
tarball?
I will try to have the HISTORY/release.sgml file ready for September 1.
I am attaching the open items list.
--
Bruce Momjian
I have reviewed your patch, and it is a thorough job. Unfortunately,
our code has drifted dramatically since 7.2 in the areas you patched.
Would you be able to download our CVS or current snapshot and submit a
patch based on that code?
In fact, we have applied a batch of snprintf fixes already
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Neil Conway wrote:
> Sir Mordred The Traitor <
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > That SELECT syntax is already too confusing. I don't want to add an
> > additional documentation specification that provides no value to users.
>
> The value of the documentation, especially the reference manual, is that
> it provides an aut
>> But we have decode():
It is a different decode function, more akin to "case when".
>> Just to give you a fair warning: I'm not going to be in favor of
adding any "Oracle compatibility" functionality that overlaps with
existing and/or standardized functionality.
I wouldn't even dream of
Bruce Momjian writes:
> That SELECT syntax is already too confusing. I don't want to add an
> additional documentation specification that provides no value to users.
The value of the documentation, especially the reference manual, is that
it provides an authorative source of what works and what
Sir Mordred The Traitor <[EMAIL PROTECTED]> writes:
> Upon invoking a polygon(integer, circle) function a
> src/backend/utils/adt/geo_ops.c:circle_poly() function will gets
> called, which suffers from a buffer overflow.
>
> 2) A src/backend/adt/utils/geo_ops.c:path_encode() fails to detect a
> b
Larry Rosenman wrote:
> > > 3. Not sure what the "original" is for -- you're not transforming
> > > anything.
> >
> > Agreed. Just call it "Error query". Seems clear to me.
> What about rule(s) transformation(s)? Will we see the real query or the
> transformed query?
Well, looking at Gavin's
On Wed, 2002-08-28 at 14:05, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Gavin Sherry writes:
> >
> > > Attached is the patch. debug_print_error_query is set to false by default.
> > >
> > > For want of a better phrase, I've prepended 'original query: ' to the
> > > error message to highli
Peter Eisentraut wrote:
> Gavin Sherry writes:
>
> > Attached is the patch. debug_print_error_query is set to false by default.
> >
> > For want of a better phrase, I've prepended 'original query: ' to the
> > error message to highlight why it is in the log.
>
> >From your resident How-To-Name-S
On Wed, 28 Aug 2002, Lamar Owen wrote:
> On Wednesday 28 August 2002 10:35 am, Marc G. Fournier wrote:
> > having never had to do it before, do you know what the procedure is?
>
> Post to [EMAIL PROTECTED] -- it's moderated, and I don't know if
> there's a subscription requirement.
>
Lamar poste
Peter Eisentraut wrote:
> Marc Lavergne writes:
>
> > This covers a few different sub-projects so I'm breaking it down in
> > order of how I'm going to attack it.
>
> Just to give you a fair warning: I'm not going to be in favor of adding
> any "Oracle compatibility" functionality that overlaps
On Wednesday 28 August 2002 02:32 pm, Lamar Owen wrote:
> On Wednesday 28 August 2002 10:35 am, Marc G. Fournier wrote:
> > having never had to do it before, do you know what the procedure is?
>
> Post to [EMAIL PROTECTED] -- it's moderated, and I don't know if
> there's a subscription requirement
On August 28, 2002 02:07 pm, D'Arcy J.M. Cain wrote:
> I had also tried changing palloc.h and mcxt.c to turn MemoryContextAlloc()
> into a macro that called a modified version of the real one to try to
> narrow down where it was being called from but that wouldn't even run. Is
> there another fil
On Wednesday 28 August 2002 10:35 am, Marc G. Fournier wrote:
> having never had to do it before, do you know what the procedure is?
Post to [EMAIL PROTECTED] -- it's moderated, and I don't know if
there's a subscription requirement.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is a resend of my previous email which was stucked at moderation
approval.. and as I don't know if anyone actually does that in your
list, I'm resending this now.
Hi,
I'm very new to this project and inspired by recent security release, I
start
... is now implemented.
But alterations done to the bootstrap user are not dumped. This is
consistent with the fact that other attributes such as the password are
not dumped either. It would be rather involved to implement this, since
at the time of the dump you don't know the name of the futur
Christopher Kings-Lynne writes:
> Do you think that 'original query: ..' looks a bit like bad english? Should
> it be properly capitalised? ie. 'Original query: ...'? Just nitpicking...
I find it's generally better to not capitalize anything in program
messages, unless the sentence/paragraph
Gavin Sherry writes:
> Attached is the patch. debug_print_error_query is set to false by default.
>
> For want of a better phrase, I've prepended 'original query: ' to the
> error message to highlight why it is in the log.
>From your resident How-To-Name-Stuff Nitpicker:
1. The names of the deb
Marc Lavergne writes:
> This covers a few different sub-projects so I'm breaking it down in
> order of how I'm going to attack it.
Just to give you a fair warning: I'm not going to be in favor of adding
any "Oracle compatibility" functionality that overlaps with existing
and/or standardized fun
On August 28, 2002 12:48 pm, D'Arcy J.M. Cain wrote:
> On August 28, 2002 09:23 am, Tom Lane wrote:
> > The behavior looks a lot like a memory clobber, so perhaps the key
> > variable is some difference in malloc's allocation strategy, causing
> > two items to be adjacent in NetBSD where they are
On August 28, 2002 09:23 am, Tom Lane wrote:
> The behavior looks a lot like a memory clobber, so perhaps the key
> variable is some difference in malloc's allocation strategy, causing
> two items to be adjacent in NetBSD where they are not on the other
> platforms we've tried.
Hmm. I might try
Title: RE: [HACKERS] tell Bugtraq about 7.2.2
oops, sorry your correct.
- Stuart
> -Original Message-
> From: Gavin Sherry [mailto:[EMAIL PROTECTED]]
> Sent: 28 August 2002 15:57
> To: Marc G. Fournier
> Cc: Henshall, Stuart - WCP; '[EMAIL PROTECTED]'
> Subject: Re: [HACKERS] tell Bu
On Wed, 28 Aug 2002, Christopher Kings-Lynne wrote:
> Now that we have prepared statements, should the foreign key code be changed
> to use them? I think it's highly likely that they will be reused in a
> connection. Might be an idea.
It might be worth doing eventually just to standardize, but
On Wed, 28 Aug 2002, Marc G. Fournier wrote:
>
> having never had to do it before, do you know what the procedure is?
I thought the announcement was forwarded to Bugtraq by Lamar?
---
Date: Fri, 23 Aug 2002 23:35:59 -0400
From: Lamar Owen <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Fwd:
Title: RE: [HACKERS] tell Bugtraq about 7.2.2
No idea sorry :(
- Stuart
> -Original Message-
> From: Marc G. Fournier [mailto:[EMAIL PROTECTED]]
> Sent: 28 August 2002 15:36
> To: Henshall, Stuart - WCP
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: [HACKERS] tell Bugtraq about 7.2.2
>
>
OK, applied with documenation updates showing only the new syntax.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Larry Rosenman wrote:
> >> Why? If both old and new are acceptable, why not document it?
Rod Taylor wrote:
> > Doesn't the need for a note explaining that we're supporting the old
> > syntax say to you that the documentation also needs to say we support
> > the old syntax? I can see the bug reports now saying "this is clearly
> > not what it says in the docs"...
>
>
> Yes, both shou
having never had to do it before, do you know what the procedure is?
On Wed, 28 Aug 2002, Henshall, Stuart - WCP wrote:
> Does someone from core want to inform bugtraq about 7.2.2?
> Cheers,
> - Stuart
>
> Westcountry Design & Print,
> Heron Road, Sowton, Exeter.
> EX2 7NF - also at -
> 17 Bres
On Wed, 2002-08-28 at 10:24, Robert Treat wrote:
> On Wed, 2002-08-28 at 10:11, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Larry Rosenman wrote:
> > >> Why? If both old and new are acceptable, why not document it?
> > >> (Just curious, I'm not wedded to it).
> >
> > > W
Robert Treat wrote:
> On Wed, 2002-08-28 at 10:11, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Larry Rosenman wrote:
> > >> Why? If both old and new are acceptable, why not document it?
> > >> (Just curious, I'm not wedded to it).
> >
> > > Well, showing both versions ad
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Larry Rosenman wrote:
> >> Why? If both old and new are acceptable, why not document it?
> >> (Just curious, I'm not wedded to it).
>
> > Well, showing both versions adds confusion for no good reason,
>
> Yes, particularly conside
On Wed, 2002-08-28 at 10:11, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Larry Rosenman wrote:
> >> Why? If both old and new are acceptable, why not document it?
> >> (Just curious, I'm not wedded to it).
>
> > Well, showing both versions adds confusion for no good reason,
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Larry Rosenman wrote:
>> Why? If both old and new are acceptable, why not document it?
>> (Just curious, I'm not wedded to it).
> Well, showing both versions adds confusion for no good reason,
Yes, particularly considering that LIMIT ... FOR UPDATE c
On Wed, 2002-08-28 at 08:52, Bruce Momjian wrote:
> Larry Rosenman wrote:
> > On Tue, 2002-08-27 at 23:29, Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > OK, patch attached. It was actually easier than I thought. We have to
> > > > decide if we are going to remove the o
Larry Rosenman wrote:
> On Tue, 2002-08-27 at 23:29, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > OK, patch attached. It was actually easier than I thought. We have to
> > > decide if we are going to remove the old syntax in 7.4.
> >
> > I'd say "no". There's no compell
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Now that we have prepared statements, should the foreign key code be changed
> to use them? I think it's highly likely that they will be reused in a
> connection. Might be an idea.
Waste of time; the FK code already does this for itself.
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
>> Could you try CVS tip on one of the boxes where you see the failure?
>> That'd help to narrow down the issue.
> Same issue. It must be a NetBSD issue but I can't think what.
The behavior looks a lot like a memory clobber, so perhaps the key
vari
Oliver Elphick <[EMAIL PROTECTED]> writes:
> If we go to a thorough solution for virtual local databases, local users
> of other databases ought to be completely invisible.
Perhaps. I'm not convinced of that, but it's a defensible position.
> I can't see how a group within a local database coul
On Tue, 2002-08-27 at 23:29, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, patch attached. It was actually easier than I thought. We have to
> > decide if we are going to remove the old syntax in 7.4.
>
> I'd say "no". There's no compelling reason to break backward
> com
//@(#) Mordred Labs advisory 0x0005
Release data: 23/08/02
Name: Several buffer overruns in PostgreSQL
Versions affected: all versions
Risk: from average to low
--[ Description:
PostgreSQL provides you with several builint geo types
(circle,polygon,box...etc).
Unfortunately the code for geo f
Title: tell Bugtraq about 7.2.2
Does someone from core want to inform bugtraq about 7.2.2?
Cheers,
- Stuart
Westcountry Design & Print,
Heron Road, Sowton, Exeter.
EX2 7NF - also at -
17 Brest Road, Derriford,
Plymouth. PL6 5AA
England
www.westcountry-design-print.co.uk
On Tue, Aug 27, 2002 at 10:45:24PM -0400, Bruce Momjian wrote:
>
> OK, patch attached. It was actually easier than I thought. We have to
> decide if we are going to remove the old syntax in 7.4.
>
> Regression tests pass. No doc updates yet.
Thanks alot! I don't mind keeping the old syntax.
On August 27, 2002 06:20 pm, Tom Lane wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > How about that --enable-multibyte?
>
> --enable-multibyte is default (indeed only) option on CVS tip,
> so that's not it. Ditto locale.
>
> Could you try CVS tip on one of the boxes where you see the
I tested this patch and I can confirm that it works very well on
FreeBSD/Alpha! This is such a cool feature - it's going to make my life so
much easier!
Do you think that 'original query: ..' looks a bit like bad english? Should
it be properly capitalised? ie. 'Original query: ...'? Just nitp
> My guess, seeing as very few probably use LIMIT and FOR UPDATE together,
> is to swap them and document it in the release notes. Was I correct in
> my guess?
Sounds good to me.
Andreas
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postma
76 matches
Mail list logo
