Hi all,
I get the following when I attempt to build outside of the source tree.
All goes well until
make[4]: Entering directory
`/home/jgray/postgres/pg-build/src/backend/utils/mb/conversion_procs/ascii_and_mic'
Makefile:11: ../proc.mk: No such file or directory
make[4]: *** No rule to make
On Mon, 19 Aug 2002 [EMAIL PROTECTED] wrote:
$input = user'name;
INSERT INTO db (name) VALUES ('$input');
will fail because the ' in the input needs to be escaped with a
backslash.
It will fail because you're doing this a very, very, very bad way.
Why rewrite this kind of stuff when the
On Mon, 19 Aug 2002, Tom Lane wrote:
Justin Clift [EMAIL PROTECTED] writes:
From the info still around, this looks to mean that the cash_words()
problem was fixed, but the cash_out() problem was harder to fix.
Tom/Bruce, is that correct?
The cash_out problem can't really be fixed until
On Mon, 19 Aug 2002, Tom Lane wrote:
Justin Clift [EMAIL PROTECTED] writes:
From the info still around, this looks to mean that the cash_words()
problem was fixed, but the cash_out() problem was harder to fix.
Tom/Bruce, is that correct?
The cash_out problem can't really be fixed
Looks like the expected files weren't updated.
Probably my fault, but the tests themselves are fine.
On Tue, 2002-08-20 at 01:37, Neil Conway wrote:
The 'type_sanity' and 'domain' regression tests seem to fail with CVS
HEAD. Here's the diff:
*** ./expected/type_sanity.outSun Aug 4
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 original creator of the type I probably have the most emotional
I just got the latest beta and it compiles ecpg grammar correctly! I had
to make one change to my source though as bison no longer accepts a comma inside the
token list.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
[EMAIL PROTECTED] (Curt Sampson) wrote in
On Mon, 19 Aug 2002 [EMAIL PROTECTED] wrote:
$input = user'name;
INSERT INTO db (name) VALUES ('$input');
will fail because the ' in the input needs to be escaped with a
backslash.
It will fail because you're doing this a very, very, very bad
On Tue, 20 Aug 2002, 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 original creator
On Mon, Aug 19, 2002 at 22:35:26 -0700,
Most computer virus problems are caused by buffer overrun. Someone
decided it wasn't very important.
I disaggree with this. Most computer viruses that I see are rely on
poorly designed software and poorly trained users to propagate.
Buffer overruns
Justin Clift wrote:
Hi Mark,
Mark Pritchard wrote:
[...]
Finally, question the due dilligence process that selects an ISP partner who
would leave a database open to the world, even if they run unbreakable
Oracle :)
This is the one point of yours I don't feel you've quite got
Vince Vielhaber [EMAIL PROTECTED] writes:
On Mon, 19 Aug 2002, Tom Lane wrote:
I'd like to see something done about this fairly soon, but it's not
happening for 7.3 ...
Can we trap and just return an error before it goes into the weeds and
put the subdividing opaque fix in later?
I don't
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 it can't be exploited. There is many cases where this
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 what
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 in
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-reference
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 original
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 course
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. This means
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
task of
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 data type
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, every output
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, when the
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 function for a built-in
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 type in
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 in order
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
*
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 has. CVS
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.
This
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
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
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
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 kluge
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
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, or
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
and
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
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
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
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 caused by
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's
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
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
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 caused by
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
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
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
-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 PROTECTED]
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 that is
-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 if
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 or a security
-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 wrote
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
.--[ 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
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
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
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
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,
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
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 be
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 currently have
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'
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
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
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 would match with any.
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, void and
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 in that case, already
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?
[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 turn a
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?
We can't
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 the semantics,
(b) we
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 other db's.
I want
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 will be
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'
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)
Vince
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 runtime type
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
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, the
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 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 way Neil
did
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?
I
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
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 ...
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 to
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 Eisentraut
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
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.
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 it
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.
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
test=# \df iso8859_1_to_utf8
List of functions
Result data type | Schema | Name| Argument data types
--++---+-
integer | pg_catalog |
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 buffer
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
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 release
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
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 make
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, --
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
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 7.3
1 - 100 of 102 matches
Mail list logo
