On Thu, 22 Aug 2002, Christopher Kings-Lynne wrote:
> Hi,
>
> ltree is good and fast at indexing hierarchies, right? XML is a standard
> way of storing hierarchies, right? Would there be any way of allowing ltree
> to index XML text fields to allow really fast XPath searches?
I was waiting thi
Are we all caught up now on the known bugs/fixes? Would it be reasonably
safe to do up a quick v7.2.2 Security Fix Release tomorrow afternoon?
On Thu, 22 Aug 2002, Bruce Momjian wrote:
>
> OK, I have applied this to 7.2.X.
>
> I have applied the lpad/rpad/repeat patch to CVS head. I assume yo
OK, I have applied this to 7.2.X.
I have applied the lpad/rpad/repeat patch to CVS head. I assume you do
not want the others applied to CVS head because the fixes are already present.
---
Neil Conway wrote:
> Neil Conway
Neil Conway <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
> What would you like done with the patch you submitted?
>>
>> I'd like to see it applied to CVS HEAD and REL7_2_STABLE.
> Uh, sorry -- wrote that without thinking. I'd
Neil Conway <[EMAIL PROTECTED]> writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What would you like done with the patch you submitted?
>
> I'd like to see it applied to CVS HEAD and REL7_2_STABLE.
Uh, sorry -- wrote that without thinking. I'd like to see the patch
applied to REL7_2_STABL
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What would you like done with the patch you submitted?
I'd like to see it applied to CVS HEAD and REL7_2_STABLE.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
---(end of broadcast)-
What would you like done with the patch you submitted?
---
Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> > > Neil Conway <[EMAIL PROTECTED]> writes:
> > > > The handling of the TZ envi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
> > Neil Conway <[EMAIL PROTECTED]> writes:
> > > The handling of the TZ environmental variable is subject to a buffer
> > > overrun.
> >
> > This problem is long gone in current sources, no?
I quickly tested current sources, and it see
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> If the {s|g}etrlimit warnings are indeed the only ones (i.e., none about
> open, fseek, write, read, etc.) then this is either a bug or there's
> something wrong in the include file order or something like that.
No such luck. Here's a more complete
Patch applied. Thanks.
---
Neil Conway wrote:
> Vince Vielhaber <[EMAIL PROTECTED]> writes:
> > And another one.
>
> This patch should fix the problem. Doesn't include my previous patch
> for repeat(). Again, somewhat of
Patch applied. Thanks.
---
Neil Conway wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
> > Neil Conway <[EMAIL PROTECTED]> writes:
> > > + /* Check for integer overflow */
> > > + if (tlen / slen != count)
>
Yep, let's create the project.
---
Marc G. Fournier wrote:
> On Wed, 21 Aug 2002, Bruce Momjian wrote:
>
> >
> > I knew that was coming. Some have been concerned that though Edmund
> > said OK, there is some new person wh
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > The handling of the TZ environmental variable is subject to a buffer
> > overrun.
>
> This problem is long gone in current sources, no?
>
The patch looks like it does prevent some problems.
--
Bruce Momjian
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Ok, now I vote, that you don't implement "any" and use "opaque".
> I don't think we want two types that do the same thing.
> Is it that you like the name "any" more than "opaque" ?
No, it's that I want to deprecate "opaque" so that we can
Neil Conway <[EMAIL PROTECTED]> writes:
> The handling of the TZ environmental variable is subject to a buffer
> overrun.
This problem is long gone in current sources, no?
regards, tom lane
---(end of broadcast)---
TIP 3: i
On Wed, 21 Aug 2002, Bruce Momjian wrote:
>
> I knew that was coming. Some have been concerned that though Edmund
> said OK, there is some new person who is the maintainer, though you
> would think Edmund would be the final word on that.
>
> Anyway, I will do it now, or as soon as I empty the pa
I knew that was coming. Some have been concerned that though Edmund
said OK, there is some new person who is the maintainer, though you
would think Edmund would be the final word on that.
Anyway, I will do it now, or as soon as I empty the patch queue.
'K, wanna do DBD::Pg next? :)
On Wed, 21 Aug 2002, Bruce Momjian wrote:
>
> Done.
>
> ---
>
> Bruce Momjian wrote:
> >
> > I will remove it from our cvs and move it over, and clean up our SGML to
> > compile properly. I ca
Done.
---
Bruce Momjian wrote:
>
> I will remove it from our cvs and move it over, and clean up our SGML to
> compile properly. I can do that much.
>
>
I will remove it from our cvs and move it over, and clean up our SGML to
compile properly. I can do that much.
---
Marc G. Fournier wrote:
> On Wed, 21 Aug 2002, Bruce Momjian wrote:
>
> >
> > I can remove it cleanly, but
Hi,
ltree is good and fast at indexing hierarchies, right? XML is a standard
way of storing hierarchies, right? Would there be any way of allowing ltree
to index XML text fields to allow really fast XPath searches?
Chris
---(end of broadcast)--
I appreciate you and other guys who has been working for this
problem.
--
Tatsuo Ishii
> Thanks. Fixed. I had a '[' on the first line of one of the makefiles.
> ---
>
> Neil Conway wrote:
> > Bruce Momjian <[EMAIL PROTECT
On Wed, 21 Aug 2002, Bruce Momjian wrote:
>
> I can remove it cleanly, but I have no idea how to add the SGML in a way
> that will allow it to build.
Anyone with some time on their hands that knows SGML enough to do this? :)
For now, can you extract what is required and commit it to the project
On Thu, 22 Aug 2002, Christopher Kings-Lynne wrote:
> Where can we see the new portal? Maybe it should be designed in such a way
> as to not use image links at all. From all my experience in doing
> websites - that'd be a _really_ good idea.
I don't believe we are using image links on the new
Yea, that was my booboo, fixed now.
---
Sean Chittenden wrote:
> > > > > On FreeBSD/Alpha, CVS gives [trouble]
> > > >
> > > > I'm currently having to use "configure --disable-largefile" on HPUX;
> > > > looks like you'll
Where can we see the new portal? Maybe it should be designed in such a way
as to not use image links at all. From all my experience in doing
websites - that'd be a _really_ good idea.
Chris
> > There will be on the new portal, but you are right, we should
> have such on
> > the current one unt
I can remove it cleanly, but I have no idea how to add the SGML in a way
that will allow it to build.
---
Marc G. Fournier wrote:
>
> That's one thing that I can't touch, since I have no idea about SGML :(
>
> Bruce, can
On Wed, 21 Aug 2002, Marc G. Fournier wrote:
>
> There will be on the new portal, but you are right, we should have such on
> the current one until the new portal is in place ...
>
> Vince, can you add a link to it off the menus themselves on the left side?
Sure. Make me a button that matches t
Thanks. Fixed. I had a '[' on the first line of one of the makefiles.
---
Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, patch applied to all Makefiles, as outlined by Peter.
>
> I see this in cur
> > > > On FreeBSD/Alpha, CVS gives [trouble]
> > >
> > > I'm currently having to use "configure --disable-largefile" on HPUX;
> > > looks like you'll have to do the same until Peter finishes ironing out
> > > the wrinkles with autoconfiguring largefile support. It would be
> > > helpful if you'
I get the same - FreeBSD/Alpha.
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Neil Conway
> Sent: Thursday, 22 August 2002 7:13 AM
> To: Bruce Momjian
> Cc: Peter Eisentraut; Tatsuo Ishii; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROT
There will be on the new portal, but you are right, we should have such on
the current one until the new portal is in place ...
Vince, can you add a link to it off the menus themselves on the left side?
On Thu, 22 Aug 2002, Christopher Kings-Lynne wrote:
> Can we perhaps have very prominent li
Can we perhaps have very prominent linking to gborg from the postgresql.org
home page? Especially now that there's libpq++ and stuff on there?
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Marc G. Fournier
> Sent: Thursday, 22 August 2002
> > If we are going to delay beta, we should decide now, not at the end of
> > August, and the delay should be until the end of September. The big
> > question is whether we have enough material to warrant a delay.
>
> Beta goes down in 1 week ... if we follow what we had talked about before,
> w
On Wed, 21 Aug 2002, Gavin Sherry wrote:
> On Tue, 20 Aug 2002, Thomas Lockhart wrote:
>
> > ...
> > > So I think that fixing the opaque problems in 7.2.x is simply
> > > impossible. Given that, the question is whether we should make a 7.2.2
> > > release with fixes for the other security holes
That's one thing that I can't touch, since I have no idea about SGML :(
Bruce, can you extract that and add it to the CVS repository for libpq++?
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscr
they are no longer on the central repository, but are on GBorg ... I've
made the appropriate chagnes to configure and Makefiles to reflect the
fact that libpq++ is no longer part of the central distribution, *but* I
used 'cvs remove' to remove the files themselves, so that the old branches
(ie. i
Morning all ...
This afternoon, Bruce Momjiam created a new project on GBorg for
libpq++, and Jeroen T. Vermeulen created one for libpqxx ... Both projects
source directory from the central CVS repository have been copied over,
including full history logs, and can be viewed at:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, patch applied to all Makefiles, as outlined by Peter.
I see this in current CVS:
make[3]: Entering directory `/home/nconway/pgsql/src/backend/utils/mb/conversion_procs'
make[4]: Entering directory
`/home/nconway/pgsql/src/backend/utils/mb/conversi
> > > On FreeBSD/Alpha, CVS gives [trouble]
> >
> > I'm currently having to use "configure --disable-largefile" on HPUX;
> > looks like you'll have to do the same until Peter finishes ironing out
> > the wrinkles with autoconfiguring largefile support. It would be
> > helpful if you'd poke into
OK, patch applied to all Makefiles, as outlined by Peter.
---
Peter Eisentraut wrote:
> Tatsuo Ishii writes:
>
> > I have applied following changes and am getting:
> >
> > make: *** No rule to make target `ascii_and_mic.o'
[EMAIL PROTECTED] (Florian Weimer) wrote
> [EMAIL PROTECTED] writes:
>
>> if you are going to be passing any user input to the database, you
>> must/should validate in some manner before blindly passing it to the db.
>> The db can and should guarantee data integrity, but the database cannot
>
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > Also, even with configure --disable-largefile, I find that pg_config.h
> > still contains
> >
> > /* Define to 1 to make fseeko visible on some hosts. */
> > #define _LARGEFILE_SOURCE 1
> >
> > /* Define to 1 if fseeko (and presumably ftello) exist
Yep, that's the plan!
---
Robert Treat wrote:
> Let me see if I have my "release dates" straight:
>
> A 7.2.2 release in the next week or so that fixes the bugtraq buffer
> overflows and timestamp issues
>
> A 7.3 beta on
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Vince Vielhaber <[EMAIL PROTECTED]> writes:
> > > Here's yet another. He claims malicious code can be run on the server
> > > with this one.
> >
> > regression=# select repeat('xxx',1431655765);
> > server clos
Tom Lane writes:
> Okay. Are you intending to work on it? I was thinking of doing some
> cleanup work in parse_coerce, but will refrain from joggling your elbow
> if you're going to deal with it.
Feel free.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcas
Tatsuo Ishii writes:
> I have applied following changes and am getting:
>
> make: *** No rule to make target `ascii_and_mic.o', needed by
>`libascii_and_mic.so.0.0'. Stop.
>
> under one of a conversion directory. The weird thing is I do not get
> this if I do a build "inside" the source tree. A
Christopher Kings-Lynne writes:
> 1. How do you compile contribs with full debugging symbols. I always get
> heuristic-fencepost-blah probs with gdb even though I've configured postgres
> with all the debugging stuff.
First, compile without optimization (-O0). Second, using LOAD to load the
sh
Bruce Momjian writes:
> This may be a case where we have to do some beta testing on our own. I
> will grab the bison beta myself for my machine.
I imagine that bison doesn't get a lot of beta testing, since people don't
have a whole bunch of production grammars lying around that they want to
upg
Tom Lane writes:
> /usr/include/sys/resource.h: In function `getrlimit':
> /usr/include/sys/resource.h:168: warning: implicit declaration of function
>`__getrlimit64'
> /usr/include/sys/resource.h: In function `setrlimit':
> /usr/include/sys/resource.h:170: warning: implicit declaration of funct
Tom Lane writes:
> Also, even with configure --disable-largefile, I find that pg_config.h
> still contains
>
> /* Define to 1 to make fseeko visible on some hosts. */
> #define _LARGEFILE_SOURCE 1
>
> /* Define to 1 if fseeko (and presumably ftello) exists and is declared. */
> #define HAVE_FSEEK
Tatsuo Ishii writes:
> Are you sure that backend gains more performance than 1GB segmented
> file (I mean large file support turn on LET_OS_MANAGE_FILESIZE)?
No idea. My change only enables access to large files, it doesn't change
the segmentation logic in the backend. The main use at this poi
> > On FreeBSD/Alpha, CVS gives [trouble]
>
> I'm currently having to use "configure --disable-largefile" on HPUX;
> looks like you'll have to do the same until Peter finishes ironing out
> the wrinkles with autoconfiguring largefile support. It would be
> helpful if you'd poke into your system
On 21 Aug 2002, Robert Treat wrote:
> Let me see if I have my "release dates" straight:
>
> A 7.2.2 release in the next week or so that fixes the bugtraq buffer
> overflows and timestamp issues
>
> A 7.3 beta on Sept 1st that has all the new schema jazz and also the
> fixes for opaque (as well as
Let me see if I have my "release dates" straight:
A 7.2.2 release in the next week or so that fixes the bugtraq buffer
overflows and timestamp issues
A 7.3 beta on Sept 1st that has all the new schema jazz and also the
fixes for opaque (as well as other stuff from todo) during which time we
get
On Wed, 21 Aug 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On 21 Aug 2002, Rod Taylor wrote:
> >
> > > Agreed. If patches are applied to the 7.4 branch as fast as normal,
> > > then maybe 7.4 will only be 6 months out with well tested Windows, PIT,
> > > etc. code that gets applied
Marc G. Fournier wrote:
> On 21 Aug 2002, Rod Taylor wrote:
>
> > Agreed. If patches are applied to the 7.4 branch as fast as normal,
> > then maybe 7.4 will only be 6 months out with well tested Windows, PIT,
> > etc. code that gets applied this October.
> >
> > Whats the intended branchpoint?
OK, beta starts on time, September 1. I agree we should keep the
agreed-upon date, and that the propsed features aren't ready, but I had
to let the discussion happen so people felt their opinions where being
heard.
---
Mar
On 21 Aug 2002, Rod Taylor wrote:
> Agreed. If patches are applied to the 7.4 branch as fast as normal,
> then maybe 7.4 will only be 6 months out with well tested Windows, PIT,
> etc. code that gets applied this October.
>
> Whats the intended branchpoint? Beta with less than 5 patches? 3rd
>
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:
> Neil Conway <[EMAIL PROTE
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 <
On Wed, 21 Aug 2002, Bruce Momjian wrote:
> Justin Clift wrote:
> > Reckon it's worth asking him, to find out if he'd be interested in this?
>
>
> I wouldn't do it yet until we know if we are going to delay.
Any security audit of the code should *not* be done while the code is in
flux, and if we
On Wed, 21 Aug 2002, Bruce Momjian wrote:
> Justin Clift wrote:
> > Only two things which have the potential to be worth waiting for, from
> > what I'm aware of. There may be others:
> >
> > - Find out from Sir Mordred if he wants to take a look at the CVS
> >version of code and audit in th
On Wed, 2002-08-21 at 13:50, Marc G. Fournier wrote:
> On Wed, 21 Aug 2002, Bruce Momjian wrote:
>
> >
> > We learned a few lessons from previous releases. First, don't delay
> > the beta by days/weeks that drag on. Delay one month at a time.
> > Second, don't decide on a further delay the day
On Thu, 22 Aug 2002, Justin Clift wrote:
> - Find out from Sir Mordred if he wants to take a look at the CVS
>version of code and audit in that for a bit, Just In Case he turns
>up something that's serious and requires substantial re-work.
>Although it means he wouldn't have a bunch
On Wed, 21 Aug 2002, Bruce Momjian wrote:
>
> We learned a few lessons from previous releases. First, don't delay
> the beta by days/weeks that drag on. Delay one month at a time.
> Second, don't decide on a further delay the day before you are going to
> go beta. Multiple short-period delays
As you probably know, PostgreSQL is quickly approaching the beta period
for its next release (7.3).
It would be heavily appreciated if you could attack the new source base
starting now and throughout the beta period in an attempt to make the
next release extra secure and stable from the outset.
On 21 Aug 2002, Robert Treat wrote:
> Assuming that we do go ahead with a 7.2.2 release, can we get some kind
> of unofficial statement on pushing back the 7.3 beta? I know Tom was
v7.3 goes beta Sept 1st ... v7.2.2 will be purely a security bugfix
release, with no changes in functionality that
Neil Conway <[EMAIL PROTECTED]> writes:
> Sir Mordred The Traitor <[EMAIL PROTECTED]> writes:
> > There exists a buffer overflow in a SET TIME ZONE command, that
> > allows an attacker to execute malicious code.
>
> Here's a patch for the problem. I also fixed some other potential
> buffer overru
> > I did not mean visible, I meant useable, like in
> > create function xx(any) returns text ...;
> > If that is possible, what is the difference to opaque ?
>
> "any" will have the same behavior that "opaque" used to have, yes.
Ok, now I vote, that you don't implement "any" and use "opaqu
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> I did not mean visible, I meant useable, like in
> create function xx(any) returns text ...;
> If that is possible, what is the difference to opaque ?
"any" will have the same behavior that "opaque" used to have, yes.
Good point; please ask him. We have at least on month in beta.
---
Rod Taylor wrote:
> On Wed, 2002-08-21 at 13:13, Bruce Momjian wrote:
> > Justin Clift wrote:
> > > Bruce Momjian wrote:
> > > >
> > > > Justin Clift wro
Peter, did you go around and remove sys/types.h from all the include
files now that it is in c.h?
---
Peter Eisentraut wrote:
> Christopher Kings-Lynne writes:
>
> > On FreeBSD/Alpha, CVS gives:
>
> > pg_backup_archiver.h
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:
> Vince Vielhaber <[EMAIL P
On Wed, 2002-08-21 at 13:13, Bruce Momjian wrote:
> Justin Clift wrote:
> > Bruce Momjian wrote:
> > >
> > > Justin Clift wrote:
> > > > Only two things which have the potential to be worth waiting for, from
> > > > what I'm aware of. There may be others:
> > > >
> > > > - Find out from Sir Mor
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:
> Tom Lane <[EMAIL PROTECTE
Christopher Kings-Lynne writes:
> On FreeBSD/Alpha, CVS gives:
> pg_backup_archiver.h:168: syntax error before `off_t'
I have added sys/types.h, so off_t should now be available.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
> >> For that you would have to use "any", at the moment. This would give
> >> you the same amount of type safety you have with "opaque",
> ie, none.
>
> > I would have to use some pg_proc magic to make "any" appear there,
> > since the plan was to not make it visible at the sql level, no ?
>
Justin Clift wrote:
> Bruce Momjian wrote:
> >
> > Justin Clift wrote:
> > > Only two things which have the potential to be worth waiting for, from
> > > what I'm aware of. There may be others:
> > >
> > > - Find out from Sir Mordred if he wants to take a look at the CVS
> > >version of cod
Bruce Momjian wrote:
>
> Justin Clift wrote:
> > Only two things which have the potential to be worth waiting for, from
> > what I'm aware of. There may be others:
> >
> > - Find out from Sir Mordred if he wants to take a look at the CVS
> >version of code and audit in that for a bit, Just
Justin Clift wrote:
> Only two things which have the potential to be worth waiting for, from
> what I'm aware of. There may be others:
>
> - Find out from Sir Mordred if he wants to take a look at the CVS
>version of code and audit in that for a bit, Just In Case he turns
>up something
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> For that you would have to use "any", at the moment. This would give
>> you the same amount of type safety you have with "opaque", ie, none.
> I would have to use some pg_proc magic to make "any" appear there,
> since the plan was to not
Bruce Momjian wrote:
>
> We learned a few lessons from previous releases. First, don't delay
> the beta by days/weeks that drag on. Delay one month at a time.
> Second, don't decide on a further delay the day before you are going to
> go beta. Multiple short-period delays and delays that happe
> If we are going to delay beta, we should decide now, not at the end of
> August, and the delay should be until the end of September. The big
> question is whether we have enough material to warrant a delay.
I think the "implicit casts" todo should be adressed soon,
not sure there is enough t
> > In my paper I use C functions that take "any tuple".
> > I do not yet see how I can do that without opaque if we don't
> > have a "row" but only a "trigger" type.
>
> For that you would have to use "any", at the moment. This would give
> you the same amount of type safety you have with "op
We learned a few lessons from previous releases. First, don't delay
the beta by days/weeks that drag on. Delay one month at a time.
Second, don't decide on a further delay the day before you are going to
go beta. Multiple short-period delays and delays that happen at the
last minute cause too
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> In my paper I use C functions that take "any tuple".
> I do not yet see how I can do that without opaque if we don't
> have a "row" but only a "trigger" type.
For that you would have to use "any", at the moment. This would give
you the s
Sir Mordred The Traitor <[EMAIL PROTECTED]> writes:
> There exists a buffer overflow in a SET TIME ZONE command, that
> allows an attacker to execute malicious code.
Here's a patch for the problem. I also fixed some other potential
buffer overruns nearby, and added a little paranoia to another ro
Robert Treat wrote:
>
> Assuming that we do go ahead with a 7.2.2 release, can we get some kind
> of unofficial statement on pushing back the 7.3 beta? I know Tom was
> hoping to start it by sept 1 but that seems rushed to me. Furthermore,
> between schema support and now more backward incompati
Oliver Elphick <[EMAIL PROTECTED]> writes:
> On Wed, 2002-08-21 at 15:02, Tom Lane wrote:
>> Also, it seems the safest behavior to me. "rmdir dir" won't remove a
>> nonempty directory; isn't that a pretty close analogy?
> Not really, seeing that you can't say "mkdir directory (containing these
>
> > May be a plan could be to leave opaque, but throw a notice
> > when it is used in a create stmt, like:
> > NOTICE: the use of type OPAQUE should be avoided where possible
>
> Right, that's exactly the plan.
>
> Actually, I think we can tighten the use of OPAQUE quite a bit, too.
> The only
> template1=# select current_timestamp(0) at time zone 'Australia/Sydney';
> ERROR: Time zone 'australia/sydney' not recognized
The input is done using an internal lookup, not your system's time zone
database. Much faster; setting time zone variables for every input will
be substantially slower
On Tue, 2002-08-20 at 23:34, Neil Conway wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > As for making a 7.2.2 release for the sake of form and for those
> > users who do provide access to untrusted users (universities, ISPs,
> > say) this would be pointless without the changes to opaque whi
On Wed, 2002-08-21 at 15:02, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > olly=# drop schema testing;
> > NOTICE: table testing.testa depends on schema testing
> > ERROR: Cannot drop schema testing because other objects depend on it
> > Use DROP ... CASCADE to dro
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>
>>I'll give it a shot, but a crude gameplan/general guidance to get me
>>started would be much appreciated.
>
>
> AFAIK, the only code you should need to touch is in
> src/include/utils/array.h
> src/backend/utils/adt/array
On Tue, 2002-08-20 at 19:59, [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] (Greg Copeland) wrote
> > At some point in time, you have to stand and say, "the buck stops here."
> >
>
> I agree here, but at the same time you cannot put 100% of the
> responsibility on the developers. If you are the
On Wednesday 21 August 2002 10:42 am, Sir Mordred The Traitor wrote:
> Hi.
> This post certainly contains no valuable information,
> but i feel i should clarify some points.
> 1) I like postgresql and i worked with it for a long time.
> 2) Solution like "killall -9 postmaster" was just a joke.
F
On Tue, 2002-08-20 at 18:40, Mark Pritchard wrote:
> On Tue, 20 Aug 2002 23:48, Greg Copeland wrote:
> > On Tue, 2002-08-20 at 00:35, Dann Corbit wrote:
> > > Most computer virus problems are caused by buffer overrun. Someone
> > > decided it wasn't very important.
> >
> > This is true. IMO, it
Seems like this one was lost or was filtered out...
//@(#)Mordred Labs advisory 0x0002
Release data: 19/08/02
Name: Buffer overflow in PostgreSQL
Versions affected: all versions
Risk: high
--[ Description:
There exists a buffer overflow in a SET TIME ZONE command, that
allows an attacker to exe
Hi.
This post certainly contains no valuable information,
but i feel i should clarify some points.
1) I like postgresql and i worked with it for a long time.
2) Solution like "killall -9 postmaster" was just a joke.
3) ...Hm..i forgot...maybe later ...
___
1 - 100 of 114 matches
Mail list logo
