On 20 Aug 2002, Neil Conway wrote:
> Vince Vielhaber <[EMAIL PROTECTED]> writes:
> > Here's yet another.
>
> Should someone from the core team perhaps get in contact with this guy
> and ask if he could get in contact with the development team before
> publicizing any further security holes? AFAIK
Tom Lane wrote:
>>>... Then you could actually do something interesting with
>>>a function taking anyarraytype.
>
>>This sounds very cool. I'd vote for that.
>
> Um, am I hearing a volunteer to make it happen? I have other problems
> I need to deal with ...
>
Hmmm. I guess I should be carefu
I had a test schema containing one table.
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 drop the dependent objects too
This seems a little over-rest
> It looks like the new stuff for loadable conversion modules is not
> correct for building outside the source tree; it's being careless about
> the paths it uses to find files. Tatsuo, can you fix that, or ask Peter
> for help?
I have applied following changes and am getting:
make: *** No rule
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... Then you could actually do something interesting with
>> a function taking anyarraytype.
> This sounds very cool. I'd vote for that.
Um, am I hearing a volunteer to make it happen? I have other problems
I need to deal with ...
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I'm going to change contrib/pgstattuple so that it returns a tuple
> > rather than a NOTICE using new SRF interface. I believe this way is
> > much more convenient for users. Any objection?
>
> Sure. I like the way Joe did show_all() better than the
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 (lpad(), rpad(),
> > reverse(), and the datetime overr
> Hi Tatsuo Ishii :
>
> Thank you very much for your reply. Somehow I managed to restore the data by
> creating by database in SQL_ASCII encoding. Then I changed the encoding of
> my database into EUC_CN thru "update pg_database set encoding=2". But the
> same problem happened in "vacuum verbose
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I'm going to change contrib/pgstattuple so that it returns a tuple
> rather than a NOTICE using new SRF interface. I believe this way is
> much more convenient for users. Any objection?
Sure. I like the way Joe did show_all() better than the way Neil
di
Tom Lane wrote:
> The reason I bring this up is that if we are changing the internal
> representation of arrays, we could add type OID and perhaps typmod to
> the array header, thus making an array value interpretable without any
> outside info. Then you could actually do something interesting wi
Tom Lane wrote:
> About I/O behavior: the pg_type entries for these pseudo-types will have to
> have typinput and typoutput functions. In general these I/O routines must
> just throw errors. Otherwise you could break the intended type safety by
> supplying user-written constants. For instance,
...
> 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 (lpad(), rpad(),
> reverse(), and the datetime overruns). IMHO, we should.
Just a minor point: can someone
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 which Tom
> has put forward and may/may not work on before
Hi All,
Few quick questions.
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. Makes it really hard to find probs in the
contribs.
2. Should contribs exclusively u
I'm going to change contrib/pgstattuple so that it returns a tuple
rather than a NOTICE using new SRF interface. I believe this way is
much more convenient for users. Any objection?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 4: Don't 'kill -9' the
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> They are like:
> * conv_proc(
> *INTEGER,-- source encoding id
> *INTEGER,-- destination encoding id
> *OPAQUE, -- source string (null terminated C string)
> *OPAQUE, --
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> IMO giving a directory to each conversion
> is more manageable than putting everything in single directory.
I lean towards Peter's point here. One or two files per conversion
is not unmanageable to keep in a single directory. And I have noticed
that "m
On Wed, 21 Aug 2002, Christopher Kings-Lynne wrote:
> > Should someone from the core team perhaps get in contact with this guy
> > and ask if he could get in contact with the development team before
> > publicizing any further security holes? AFAIK that is standard
> > operating procedure in most
> Should someone from the core team perhaps get in contact with this guy
> and ask if he could get in contact with the development team before
> publicizing any further security holes? AFAIK that is standard
> operating procedure in most cases...
>
> Second, it might be worth pushing a 7.2.2 relea
> Trigger functions will now be expected to take no arguments and return
> either tuple (or trigger if we call it that) or opaque. It would also be
> sensible to allow VOID in the case of AFTER triggers, but I'm inclined not
> to do so: I think it's better that a trigger function be declared in a
Neil Conway wrote:
>
> I've backpatched Thomas's fixes for the potential buffer overruns in
> the datetime code to the REL7_2_STABLE branch. The required changes
> are pretty minimal, and the code passes the regression tests.
>
> However, I haven't yet seen a test-case that demonstrates the buff
> > test=# \df iso8859_1_to_utf8
> > List of functions
> > Result data type | Schema | Name| Argument data types
>
> >
>--++---+-
> > integer | p
> Large file support is now compiled by default if available. (Use
> --disable-largefile to turn it off. That's what Autoconf gives us.)
Are you sure that backend gains more performance than 1GB segmented
file (I mean large file support turn on LET_OS_MANAGE_FILESIZE)? I
myself have not tried y
> Tatsuo, why is there one directory per encoding combination with only one
> source file each? Couldn't we put all the files in one directory?
euc_tw_and_big5 has *two* files. Also Unicode mapping files could be
moved to each directory. So the Unicode related functions might have
one more file.
> > (That's on a Unicode DB, haven't tested other encodings but AFAICT
> > this fix should still work.)
>
> Is there any chance that pg_database_encoding_max_length() could return
> zero
That's impossible or at least is the evidence of something badly
broken.
> and give a divide by zero error?
[EMAIL PROTECTED] (Greg Copeland) wrote
> Time and time again I've read what basically amounts to, "...if someone
> can crash it it's because someone is stupid enough to allow someone to
> be able to do it in the first place..." Maybe you're right. After all,
> if core developers continue to tu
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 is extremely arrogant to ignore a buffer overrun
> and announce
I've backpatched Thomas's fixes for the potential buffer overruns in
the datetime code to the REL7_2_STABLE branch. The required changes
are pretty minimal, and the code passes the regression tests.
However, I haven't yet seen a test-case that demonstrates the buffer
overrun in 7.2 code (I origin
Hi Mordred,
Thanks for doing this testing for vulnerabilities for us.
Some PostgreSQL team members have been looking to organise an "audit"
team to remove vulnerabilities like this, and your posts to BugTraq have
assisted in getting that further mobilised.
Something that is concerning us though
J.R, Richard, we only have 10 days until beta. Can you give us any
status on PITR?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> On 20 Aug 2002, Neil Conway wrote:
> Is there any chance that pg_database_encoding_max_length() could return
> zero and give a divide by zero error? Or is that trapped?
I don't think so (the array of encodings that contains the data seems
to be pre-d
On Tue, 2002-08-20 at 17:15, Tom Lane wrote:
> Yes it has. CVS logs show
>
> 2002-08-04 02:44 thomas
>
> * src/backend/utils/adt/: date.c, datetime.c, format_type.c,
> nabstime.c, timestamp.c, varlena.c: Add guard code to protect from
> buffer overruns on long date/time input
On 20 Aug 2002, 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 off-the-cuff, so I might have missed
> something...
>
> test=# select lpad('x',1431655
Tatsuo Ishii writes:
> Done. See current doc (user's guide "6.4. String Functions and
> Operators" Table 6-7 "Available conversion names") how I changed the
> conversion names.
What guideline did you follow? For example, should koi8r be koi8_r? Or
should winXXX be win_XXX?
--
Peter Eisentrau
Tom Lane writes:
> John Gray <[EMAIL PROTECTED]> writes:
> > I get the following when I attempt to build outside of the source tree.
>
> It looks like the new stuff for loadable conversion modules is not
> correct for building outside the source tree; it's being careless about
> the paths it uses
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, now that _a_ bison exists that works, how does this effect our
> > release? I don't see preproc.[ch] in CVS. Do we need this new bison
> > version on postgresql.org because Marc generates these as part of his
> > install script?
This is all an indication of our increasing usage. Several PostgreSQL
articles have appeared in the past week in _major_ media outlets, not
just the open-source press (eweek, Bloomburg), a major PostgreSQL
support company bought a Linux distribution (SRA-Turbolinux), and we
have independent proj
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> And another one.
This patch should fix the problem. Doesn't include my previous patch
for repeat(). Again, somewhat off-the-cuff, so I might have missed
something...
test=# select lpad('x',1431655765,'');
ERROR: Requested length
.--[ Dann Corbit wrote (2002/08/20 at 14:05:37) ]--
|
| ... [large snip] ...
|
| Well, of course, a well mannered team member would report the bugs
| through one of the normal channels.
| On the other hand, a malicious tester who finds these problems performs
| two valuable
> -Original Message-
> From: Frank Wiles [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 20, 2002 1:57 PM
> To: Dann Corbit
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0004:
> Multiple buffer overflows inPostgreSQL. (fwd)
>
>
> .--[ Dann Corbit
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> And another one. Sure would be nice if shit-for-brains would mention
> it to us first.
I don't even mind the "first" part, but it would certainly be polite of
him to cc: pghackers rather than expecting us to dig it off bugtraq.
But, as someone else
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Hmm, "any" would sound like it is the same as opaque. Would "any" really be
> all allowed types ? I think we would want to eliminate that altogether.
Do you plan on eliminating the COUNT() aggregate, then?
> Imho opaque is missing a runt
Tom Lane <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > + /* Check for integer overflow */
> > + if (tlen / slen != count)
> > + elog(ERROR, "Requested buffer is too large.");
>
> What about slen == 0?
Good point -- that wouldn't cause incorrect results o
Dann Corbit wrote:
> > -Original Message-
> > From: Neil Conway [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, August 20, 2002 1:44 PM
> > To: Vince Vielhaber
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0003:
> > Buffer overflow in PostgreSQL (fwd)
> >
> -Original Message-
> From: Vince Vielhaber [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 20, 2002 1:48 PM
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple
> buffer overflows inPostgreSQL. (fwd)
>
>
>
> And another one. Sure would be nice
Vince Vielhaber wrote:
>
> Here's yet another. He claims malicious code can be run on the server
> with this one.
> --[ Solution
>
> Do you still running postgresql? ...Can't believe that...
> If so, execute the following command as a root: "killall -9 postmaster",
> and wait until the patch w
On 20 Aug 2002, Neil Conway wrote:
> Vince Vielhaber <[EMAIL PROTECTED]> writes:
> > Here's yet another.
>
> Should someone from the core team perhaps get in contact with this guy
> and ask if he could get in contact with the development team before
> publicizing any further security holes? AFAIK
On Tue, 2002-08-20 at 16:46, Zeugswetter Andreas SB SD wrote:
> > >>> Hard to say what is good for those names imho, don't like
> > >>> "anytype" :-(
> > >>
> > >> How about "any"? It's a reserved word per SQL99, I think.
> >
> > > I would actually stick to opaque in that case, already used in
> -Original Message-
> From: Neil Conway [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 20, 2002 1:44 PM
> To: Vince Vielhaber
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0003:
> Buffer overflow in PostgreSQL (fwd)
>
>
> Vince Vielhaber <[EMAIL PROT
And another one. Sure would be nice if shit-for-brains would mention
it to us first.
Vince.
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
56K Nationwide Dialup from $16.00/mo a
> >>> Hard to say what is good for those names imho, don't like
> >>> "anytype" :-(
> >>
> >> How about "any"? It's a reserved word per SQL99, I think.
>
> > I would actually stick to opaque in that case, already used in other db's.
>
> I want to change the name because (a) we are changing th
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> Here's yet another.
Should someone from the core team perhaps get in contact with this guy
and ask if he could get in contact with the development team before
publicizing any further security holes? AFAIK that is standard
operating procedure in most c
Tom Lane wrote:
> > I think we should throw the notices right away, although this makes me
> > wonder in general about upgrade path. Are we ever planning to make that
> > an error, and if so, how are we going to handle functions that are coming
> > from previous versions where it was okay?
>
> W
Neil Conway <[EMAIL PROTECTED]> writes:
> + /* Check for integer overflow */
> + if (tlen / slen != count)
> + elog(ERROR, "Requested buffer is too large.");
What about slen == 0?
regards, tom lane
---(end of broadcast)
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, now that _a_ bison exists that works, how does this effect our
> release? I don't see preproc.[ch] in CVS. Do we need this new bison
> version on postgresql.org because Marc generates these as part of his
> install script?
I don't think we want a
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 closed the connection unexpectedly
>
> This is probably cau
OK, now that _a_ bison exists that works, how does this effect our
release? I don't see preproc.[ch] in CVS. Do we need this new bison
version on postgresql.org because Marc generates these as part of his
install script?
-
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>>> Hard to say what is good for those names imho, don't like
>>> "anytype" :-(
>>
>> How about "any"? It's a reserved word per SQL99, I think.
> I would actually stick to opaque
> "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> > Hard to say what is good for those names imho, don't like
> "anytype" :-(
>
> How about "any"? It's a reserved word per SQL99, I think.
I would actually stick to opaque in that case, already used in other db's.
> > I like "cstring
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> Where do we check that this:
> result = (text *) palloc(tlen);
> is even successful?
palloc elogs if it can't allocate the space; it's unlike malloc in that
respect. I believe it also has a guard to reject requests > 1Gb, so
I think it'
On Tue, 20 Aug 2002, Tom Lane wrote:
> 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 closed the connection unexpectedly
>
> This is probably cause
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 closed the connection unexpectedly
This is probably caused by integer overflow in calculating the size of
the
Nigel J. Andrews wrote:
> On Tue, 20 Aug 2002, Tom Lane wrote:
>
> > "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > >> I'd like to see something done about this fairly soon, but it's not
> > >> happening for 7.3 ...
> >
> > > Does anyone have an idea about what other functions are affected b
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Hard to say what is good for those names imho, don't like "anytype" :-(
How about "any"? It's a reserved word per SQL99, I think.
> I like "cstring", "void" and "internal".
Okay.
> Maybe "anyarray" instead of "anyarraytype".
That wou
Here's yet another. He claims malicious code can be run on the server
with this one.
Vince.
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
56K Nationwide Dialup from $16.00/mo a
SRA/Japan, my employer and a big PostgreSQL support company in Japan,
has announced they have purchased TurboLinux:
http://www.turbolinux.com/news/pr/020820.html
Here is a summary from someone on Slashdot:
* Turbolinux Inc. sold Turbolinux Japan K.K. (its Japanese
subsidary) to SRA.
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_FSEEKO 1
This strikes me as probably
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Tue, 20 Aug 2002, Tom Lane wrote:
>> Less obviously, void_in should succeed (and return nothing
>> interesting, probably just a zero datum; it can ignore its input). This
>> allows plpgsql functions to be defined to return VOID.
> Does this require
> "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> > Would it be possible to update the system tables, so that cash_out does not take
> > opaque but really takes type money ?
>
> That is part of the solution, but only part: we have hundreds of
> functions that take "opaque" because we d
On Tue, 20 Aug 2002, Tom Lane wrote:
In general I think it sounds good, so I'm only responding to places where
I want to say something specific.
> I am not by any means wedded to the above type names; does anyone have
> suggestions for better names? (In particular, I am wondering if "tuple"
> a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Large file support is now compiled by default if available.
I am now getting (on HPUX 10.20)
/usr/include/sys/resource.h: In function `getrlimit':
/usr/include/sys/resource.h:168: warning: implicit declaration of function
`__getrlimit64'
/usr/inclu
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Would it be possible to update the system tables, so that cash_out does not take
> opaque but really takes type money ?
That is part of the solution, but only part: we have hundreds of
functions that take "opaque" because we don't currentl
Rod Taylor <[EMAIL PROTECTED]> writes:
>> anyarraytype -- for array_eq, array_dims
> Will this allow generic array iterator functions in the future?
Hm. Not directly; there's still the issue of how to tell what element
type the array is. array_dims doesn't care, and I think that we have
some k
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Also, in the present state of the code a WITHOUT FUNCTION cast does
>> not work if AS ASSIGNMENT isn't given: parse_coerce.c won't ever find
>> it. Is this intentional, or just an oversight?
> It's a transition state that might b
> anyarraytype-- for array_eq, array_dims
Will this allow generic array iterator functions in the future?
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Okay, I'm tired of hearing about this, and I've decided I can make the problem
go away with a day or so's concentrated work.
Here is the plan:
Create several "pseudo types" (typtype 'p' in pg_type). We already have one
pseudo-type (RECORD), plus the logic in heap.c to reject any attempt to crea
Tom Lane writes:
> In any case we need to distinguish implicit coercion for a store from
> explicit coercion. Do your recent pg_cast changes make that any easier?
Possibly we could allow for registering both implicit and explicit cast
functions for the same combination. Or we could make cast f
Large file support is now compiled by default if available. (Use
--disable-largefile to turn it off. That's what Autoconf gives us.)
But:
The zlib library uses unsigned ints and unsigned longs for file positions
and offsets. Depending on how that is used in detail and depending on how
zlib it
Tom Lane writes:
> I think it might be a good idea to require superuser permissions to
> create a binary-equivalence cast.
OK
> Also, in the present state of the code a WITHOUT FUNCTION cast does
> not work if AS ASSIGNMENT isn't given: parse_coerce.c won't ever find
> it. Is this intentional,
John Gray <[EMAIL PROTECTED]> writes:
> I get the following when I attempt to build outside of the source tree.
It looks like the new stuff for loadable conversion modules is not
correct for building outside the source tree; it's being careless about
the paths it uses to find files. Tatsuo, can
> The cash_out problem can't really be fixed until we do something about
> subdividing type "opaque" into multiple pseudo-types with more carefully
> defined meanings. cash_out is declared cash_out(opaque) which does not
> really mean that it accepts any input type ... but one of the several
> m
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Yes, but what is currently missing is a protocol to the backend
> where a statement is prepared with placeholders and then executed
> (multiple times) with given values. Then there is no doubt what is a
> value, and what a part of the SQL.
On Tuesday 20 August 2002 12:15 pm, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Umm, but what about the reply buffer overrun advisory? I've read this
> > whole thread, and the reply advisory (AFAICT, unless I've just hit delete
> > too quickly) has NOT been addressed.
> Yes it h
Lamar Owen <[EMAIL PROTECTED]> writes:
> Umm, but what about the reply buffer overrun advisory? I've read this whole
> thread, and the reply advisory (AFAICT, unless I've just hit delete too
> quickly) has NOT been addressed.
Yes it has. CVS logs show
2002-08-04 02:44 thomas
* src/
> > with Perl and *using placeholders and bind values*, the application
> > developer has not to worry about this. So, usually I don't check the
> > values in my applications (e.g. if only values between 1 and 5 are
> > allowed and under normal circumstances only these are possible), it's the
> >
On Tuesday 20 August 2002 11:28 am, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > But going back to the idea that it seems that the only problem being
> > publicised in the 'outside world' is the cash_out(2) version can we
> > not do the restriction on acceptable input type
Joe Conway <[EMAIL PROTECTED]> writes:
> Is there ever a reason for a user to call a function with an opaque
> parameter directly? If not, can we simply REVOKE EXECUTE for these
> functions?
Not sure, but that doesn't solve the problem for array_eq and array_dims
in any case.
Good thought thou
On Tue, Aug 20, 2002 at 11:28:32AM -0400, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > But going back to the idea that it seems that the only problem being
> > publicised in the 'outside world' is the cash_out(2) version can we
> > not do the restriction on acceptable input
Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
>
>>>I'd like to see something done about this fairly soon, but it's not
>>>happening for 7.3 ...
>>
>
>>Does anyone have an idea about what other functions are affected by this?
>
>
> As a first approximation, every output funct
Michael Meskes <[EMAIL PROTECTED]> writes:
> On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote:
>> BTW, I spent some time looking at the problem, and it seems the issue
>> is not overrun of any bison internal table, but failure to compress the
>> resulting "action table" into 32K entries.
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> But going back to the idea that it seems that the only problem being
> publicised in the 'outside world' is the cash_out(2) version can we
> not do the restriction on acceptable input type in order to claim that
> the fix?
Totally pointless IMHO, w
On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote:
> BTW, I spent some time looking at the problem, and it seems the issue
> is not overrun of any bison internal table, but failure to compress the
> resulting "action table" into 32K entries. This means that the required
Ouch! This of cour
On Tue, 20 Aug 2002, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> >> I'd like to see something done about this fairly soon, but it's not
> >> happening for 7.3 ...
>
> > Does anyone have an idea about what other functions are affected by this?
>
> As a first approximation,
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> Anyone see something I missed? Tatsuo, what exactly should the function
>> signature really be for all those encoding conversion functions you just
>> added?
> test=# \df iso8859_1_to_utf8
> List of functions
> Result
Michael Meskes <[EMAIL PROTECTED]> writes:
> I just got the latest beta and it compiles ecpg grammar correctly!
This is good. Any word on when it will go to an official release?
BTW, I spent some time looking at the problem, and it seems the issue
is not overrun of any bison internal table, but
> Anyone see something I missed? Tatsuo, what exactly should the function
> signature really be for all those encoding conversion functions you just
> added?
test=# \df iso8859_1_to_utf8
List of functions
Result data type | Schema | Name|
On Tue, 2002-08-20 at 08:22, D'Arcy J.M. Cain wrote:
> On August 19, 2002 11:58 pm, Rod Taylor wrote:
> > On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
> > The simple fix is to drop the money type entirely as it serves few
> > purposes -- but there are some who use it.
>
> As the or
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
>> I'd like to see something done about this fairly soon, but it's not
>> happening for 7.3 ...
> Does anyone have an idea about what other functions are affected by this?
As a first approximation, every output function for a built-in
pass-by-refere
On Tue, 2002-08-20 at 08:05, Jan Wieck wrote:
> If you say your users need direct DB access on the SQL interface level,
> I say trash your application because the data it produces isn't worth
> the magnetism on the media. It's not that we ugently need to fix such a
> bug that can only cause a DOS
Dann Corbit wrote:
> [...]
>
> What I am saying is that there is nothing that could possibly be more
> important than fixing this, except some other known problem that could
> also cause billions of dollars worth of damage. Are there any such
> problems besides the buffer overrun problems?
And
1 - 100 of 113 matches
Mail list logo
