Christopher Kings-Lynne wrote:
>
> > Hey yep, good point.
> >
> > Is this the only way that we know of non postgresql-superusers to be
> > able to take out the server other than by extremely non-optimal,
> > resource wasting queries?
> >
> > If we release a 7.2.2 because of this, can we be pretty
On Mon, 2002-08-12 at 11:52, Curt Sampson wrote:
> On Sun, 11 Aug 2002, Don Baccus wrote:
>
> > Obviously it would require extending SQL, but since you in part argue
> > that SQL sucks in regard to the relational model this shouldn't matter,
> > right?
>
> Well, if we're going to go so far as to
On 12 Aug 2002, Hannu Krosing wrote:
> Are you saying that inheritance in SQL is something fundamentally
> different than inheritance in OO languages ?
Yes.
> > (For example, the distinction
> > between types and instances of types is critical in OO theory. What are
> > the TI equivalants of th
Tom Lane <[EMAIL PROTECTED]> writes:
> Justin Clift <[EMAIL PROTECTED]> writes:
>> Am I understanding this right:
>> - A PostgreSQL 7.2.1 server can be crashed if it gets passed certain
>> date values which would be accepted by standard "front end" parsing?
>
> AFAIK it's a buffer overrun issue
Mike Mascari <[EMAIL PROTECTED]> writes:
> I'd still think it would be a good policy to make a security release.
> However, without user resource limits in PostgreSQL, anyone can make a
> machine useless with a query like:
>
> SELECT *
> FROM pg_class a, pg_class b, pg_class c, pg_class d, pg_cl
On Mon, 12 Aug 2002, Florian Weimer wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Justin Clift <[EMAIL PROTECTED]> writes:
> >> Am I understanding this right:
> >> - A PostgreSQL 7.2.1 server can be crashed if it gets passed certain
> >> date values which would be accepted by standard "fr
On Mon, 2002-08-12 at 13:14, Curt Sampson wrote:
> On 12 Aug 2002, Hannu Krosing wrote:
>
> > Are you saying that inheritance in SQL is something fundamentally
> > different than inheritance in OO languages ?
>
> Yes.
>
...
> So is an instance a relation (a set of tuples) or a tuple?
An inst
I just got the following example:
DROP TABLE foo;
CREATE TABLE foo (login varchar(100));
INSERT INTO foo values ('abc');
DROP FUNCTION footest1(varchar(100));
CREATE FUNCTION footest1(varchar(100)) RETURNS varchar(100) AS '
DECLARE
login varchar(100);
BEGIN
Well, if it's a buffer overrun, there is certainly potential for risks
well beyond that of simply crashing the "be". It's certainly possible
that a simple bug in one cgi script or web site could allow someone to
execute code on the database host because of this bug. Assuming they
are running the
Michael Meskes <[EMAIL PROTECTED]> writes:
> CREATE FUNCTION footest1(varchar(100)) RETURNS varchar(100) AS '
> DECLARE
> login varchar(100);
> BEGIN
> SELECT INTO login login FROM foo LIMIT 1;
> RETURN login;
> END;
> ' LANGU
Greg Copeland <[EMAIL PROTECTED]> writes:
> Well, if it's a buffer overrun, there is certainly potential for risks
> well beyond that of simply crashing the "be".
It's a buffer overrun, but the data has to pass through the date/time
parser in the backend, so it's not entirely obvious how you can
Gavin Sherry <[EMAIL PROTECTED]> writes:
>> Yes, but if you just check that the date given by the user matches the
>> regular expression "[0-9]+-[0-9]+-[0-9]+", it's still possible to
>> crash the backend.
> Anyone who is using that regular expression in an attempt to validate a
> user supplied
On Mon, Aug 12, 2002 at 09:40:12AM -0400, Tom Lane wrote:
> The NULL is perfectly correct: that's the initial value of the plpgsql
> variable. The above is essentially the same as saying
> login := login;
> It is not "incorrect".
That's exactly what I thought is the reason. I just wonder i
On Mon, 2002-08-12 at 00:29, Hannu Krosing wrote:
> On Mon, 2002-08-12 at 11:52, Curt Sampson wrote:
> > On Sun, 11 Aug 2002, Don Baccus wrote:
[snip]
> > But anyway, I have no particularly huge objection to syntatic sugar
> > alone. I do have objections to it when it's not saving much typing. (It
On Mon, 12 Aug 2002, Florian Weimer wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
>
> >> Yes, but if you just check that the date given by the user matches the
> >> regular expression "[0-9]+-[0-9]+-[0-9]+", it's still possible to
> >> crash the backend.
>
> > Anyone who is using that regul
Just go with tradition and label all of your variables with a
v_. Never use columns or tablenames prefixed with a v_.
It's a quick way for determining what is what. Forcing use of a prefix
in some places and not others would not be a nice thing -- especially as
the core takes on more and more
> -Original Message-
> From: Gavin Sherry [mailto:[EMAIL PROTECTED]]
> Sent: 12 August 2002 15:15
> To: Florian Weimer
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] [SECURITY] DoS attack on backend
> possible (was: Re:
>
>
> On Mon, 12 Aug 2002, Florian Weimer wrote:
>
> > Gavin
Gavin Sherry wrote:
> As to your other point -- that this bug in the data/time code actually
> *reflects* the quality and reliability of the database itself -- you've
> really gone too far. The best software has bugs.
For example, in the current version of Oracle 9i, if a client (say
SQL*Plus)
On Fri, Aug 09, 2002 at 06:54:44PM -0700, Thomas Lockhart wrote:
> I had thought to extend the capabilities to allow resource allocation
> for individual tables and indices, which has *long* been identified as a
> desired capability by folks who are managing large systems.
Without wishing to po
In 7.2.1, the psql argument to import a file from a connected database
is \i. From the command line its -f.
Any chance we could make these consistent with eachother.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://ww
On Sat, Aug 10, 2002 at 09:21:07AM -0500, Greg Copeland wrote:
> I'm actually amazed that postgres isn't already using large file
> support. Especially for tools like dump.
Except it would only cause confusion if you ran such a program on a
system that didn't itself have largefile support. Be
On Mon, 2002-08-12 at 09:39, Andrew Sullivan wrote:
> On Sat, Aug 10, 2002 at 09:21:07AM -0500, Greg Copeland wrote:
>
> > I'm actually amazed that postgres isn't already using large file
> > support. Especially for tools like dump.
>
> Except it would only cause confusion if you ran such a pr
On Mon, Aug 12, 2002 at 10:15:46AM -0500, Greg Copeland wrote:
> If by "turn...on", you mean recompile, that's a horrible idea IMO.
Ah. Well, that is what I meant. Why is it horrible? PostgreSQL
doesn't take very long to compile.
> I guess what I'm trying to say here is, it's moving the p
On Mon, 2002-08-12 at 15:00, Greg Copeland wrote:
...
> Look a little deeper here. In other OO implementations, I can define a
> class (say class a) which has no instances (abstract base class).
> Furthermore, I can take this case and use it for building blocks
> (assuming multiple inheritance i
On Monday 12 August 2002 11:30 am, Andrew Sullivan wrote:
> The problem is not just a system-level one, but a filesystem-level
> one. Enabling 64 bits by default might be dangerous, because a DBA
> might think "oh, it supports largefiles by default" and therefore not
> notice that the filesystem
On Mon, Aug 12, 2002 at 11:44:24AM -0400, Lamar Owen wrote:
> > The problem is not just a system-level one, but a filesystem-level
> > one. Enabling 64 bits by default might be dangerous, because a DBA
> > might think "oh, it supports largefiles by default" and therefore not
> > notice that the f
On Mon, 2002-08-12 at 10:30, Andrew Sullivan wrote:
> On Mon, Aug 12, 2002 at 10:15:46AM -0500, Greg Copeland wrote:
>
> > If by "turn...on", you mean recompile, that's a horrible idea IMO.
>
> Ah. Well, that is what I meant. Why is it horrible? PostgreSQL
> doesn't take very long to compile
Uh, from the command line, you are running _only_ a (f)ile, while from
inside psql, you are (i)ncluding it in your session; the existing
values seem OK to me.
---
Rod Taylor wrote:
> In 7.2.1, the psql argument to import a
On Mon, 2002-08-12 at 11:04, Andrew Sullivan wrote:
> On Mon, Aug 12, 2002 at 11:44:24AM -0400, Lamar Owen wrote:
> > keep discussing the issues involved, and I'll see what comes of it. I don't
> > have an direct experience with the largefile support, and am learning as I go
> > with this.
>
>
On Mon, 2002-08-12 at 16:44, Lamar Owen wrote:
> Interesting point. Before I could deploy RPMs with largefile support by
> default, I would have to make sure it wouldn't silently break anything. So
> keep discussing the issues involved, and I'll see what comes of it. I don't
> have an direct
On Mon, 2002-08-12 at 10:39, Oliver Elphick wrote:
> On Mon, 2002-08-12 at 15:00, Greg Copeland wrote:
> > How exactly would you create an abstract base class for table type?
>
> CREATE TABLE abstract_base (
>cols ...,
>CONSTRAINT "No data allowed in table abstract_base!" CHECK (1 = 0)
>
On Mon, Aug 12, 2002 at 11:07:51AM -0500, Greg Copeland wrote:
> Many reasons. A DBA is not always the same thing as a developer (which
> means it's doubtful he's even going to know about needed options to pass
> -- if any).
This (and the "upgrade" argument) are simply documentation issues.
I
On Mon, Aug 12, 2002 at 11:17:31AM -0500, Greg Copeland wrote:
>
> And, what if he just remounted it read only. Mistakes will happen.
> That doesn't come across as being a strong argument to me. Besides,
> it's doubtful that a filesystem is going to be remounted while it's in
> use. Which mea
On Mon, 2002-08-12 at 11:40, Andrew Sullivan wrote:
> On Mon, Aug 12, 2002 at 11:07:51AM -0500, Greg Copeland wrote:
>
> > Many reasons. A DBA is not always the same thing as a developer (which
> > means it's doubtful he's even going to know about needed options to pass
> > -- if any).
>
> Thi
On Mon, 2002-08-12 at 11:48, Andrew Sullivan wrote:
> On Mon, Aug 12, 2002 at 11:17:31AM -0500, Greg Copeland wrote:
[snip]
> > > There are, in any case, _lots_ of problems with these large files.
>
> > All of those are SA issues.
>
> So is compiling the software correctly, if the distinctio
On Mon, 2002-08-12 at 17:30, Greg Copeland wrote:
> On Mon, 2002-08-12 at 10:39, Oliver Elphick wrote:
> > On Mon, 2002-08-12 at 15:00, Greg Copeland wrote:
> > > How exactly would you create an abstract base class for table type?
> >
> > CREATE TABLE abstract_base (
> >cols ...,
> >CONST
[EMAIL PROTECTED] (Florian Weimer) wrote in
[EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
>
>>> Yes, but if you just check that the date given by the user matches the
>>> regular expression "[0-9]+-[0-9]+-[0-9]+", it's still possible to
>>> crash the bac
On Sun, 11 Aug 2002, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > The problem I see now is that libpqxx has a completely different build
> > system and documentation system.
>
> Unless someone's going to do the work to integrate libpqxx into our
> build/documentation system,
On Mon, Aug 12, 2002 at 04:44:12PM -0300, Marc G. Fournier wrote:
> For this, all I've been waiting for is for J to get the standalone to
> build and then going to dive into that ...
I added Ray's changes a few days back, which may help. My handicap is
that I appear to be on a newer version of
Oliver Elphick writes:
> One person said:
> However compiling with largefile support will change the size
> of off_t from 32 bits to 64 bits - if postgres uses off_t or
> anything else related to file offsets in a binary struct in one
> of the database files you will break stuff p
Hello
In TODO there is an item that says "cluster all tables at once". Might
I ask, how is the system supposed to know on which indexes does it have
to cluster each table?
Maybe if some index had the indisclustered bit set one could select
that; but is it possible for some table to have more th
I thought this might be of interest to the list:
LINUXWORLD: ORACLE RELEASING CLUSTERED FILE SYSTEM CODE
http://www.idg.net/go.cgi?id=726336
"The company on Wednesday plans to post online the source code for its
new clustered file system designed for its Oracle9i Real Application
Clusters (RAC
> Maybe if some index had the indisclustered bit set one could select
> that; but is it possible for some table to have more than one index with
> it? Intuition (but no code observation) says no. And what happens with
> those tables that do not have any such index?
The bool marker sounds useful
Tatsuo Ishii wrote:
>>Now a new function similar to toast_raw_datum_size(), maybe
>>toast_raw_datum_strlen() could be used to get the original string
>>length, whether MB or not, without needing to retrieve and decompress
>>the entire datum.
>>
>>I understand we would either: have to steal anot
I've been studying the "No one parent tuple was found" problem some
more, and I've realized there are actually two distinct problems that
manifest at the same place.
Here are test procedures for duplicating the problems on-demand (these
work in either 7.2 or CVS tip):
CASE 1 (transient failure):
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Maybe if some index had the indisclustered bit set one could select
> that; but is it possible for some table to have more than one index with
> it? Intuition (but no code observation) says no.
At the moment that bit will never be set at all, unless y
On Sun, 2002-08-11 at 21:15, Christopher Kings-Lynne wrote:
> > Not a problem. I would rather them be correct.
> >
> > Worth noting that the first patch is what attempts to fix the long ->
> > int overflow issue. The second patch attempts to resolve "attisdropped"
> > column use issues with the
All of that said, the cost of the check is so small it may save someones
ass some day when they have a corrupted catalog and the below
assumptions are no longer true.
On Mon, 2002-08-12 at 18:40, Greg Copeland wrote:
> On Sun, 2002-08-11 at 21:15, Christopher Kings-Lynne wrote:
> > > Not a proble
anoncvs is still broken:
cvs server: Updating src/interfaces/libpqxx/config
cvs server: Updating src/interfaces/libpqxx/debian
cvs server: failed to create lock directory for
`/projects/cvsroot/interfaces/libpqxx/debian'
(/projects/cvsroot/interfaces/libpqxx/debian/#cvs.lock): Permission
denied
c
On Mon, Aug 12, 2002 at 11:30:36AM -0400, Andrew Sullivan wrote:
> The problem is not just a system-level one, but a filesystem-level
> one. Enabling 64 bits by default might be dangerous, because a DBA
> might think "oh, it supports largefiles by default" and therefore not
> notice that the file
should be fixed ... looks like just an ownership issue on a new directory
...
On 13 Aug 2002, Oliver Elphick wrote:
> anoncvs is still broken:
>
> cvs server: Updating src/interfaces/libpqxx/config
> cvs server: Updating src/interfaces/libpqxx/debian
> cvs server: failed to create lock directo
[Cced to hackers list]
> I'm seeing a regression test failure with the latest CVS code, in the
> 'conversion' test. I've attached the 'regression.diff' file -- the
> failure occurs consistently on my machine.
>
> I'm mailing you because I believe the test in question is for code you
> wrote). Le
On Saturday 10 August 2002 10:41 pm, Bruce Momjian wrote:
> Let me give a little history. The secondary password file was created
> at a time when we didn't encrypt with random salt over the wire, and we
> had people who wanted to share their /etc/passwd file with PostgreSQL.
[snip]
> So, based
Ok, big bundled up reply here to various people.
> From: Greg Copeland <[EMAIL PROTECTED]>
>
> > What makes things more confusing is poor understanding of a feature, not
> > the feature itself.
>
> Agreed. Just because a feature may not be well understood by the masses
> doesn't mean the feature
Curt Sampson wrote:
> ... the bugs in the postgres implementation
> of table inheritance, I've found the relational model much easier
> to use for solving problems.
No one has argued that the shortcomings (not bugs, really, just things
left out) makes the current implementation of very limited
On Mon, 2002-08-12 at 21:28, Lamar Owen wrote:
> I'm going to now go to the lagging plane -- building newer PostgreSQL for
> older Red Hat (and maybe others, if I can get enough hard drives available).
> The source RPM will still be useful to the newer distribution's maintainers
> -- but the
On Mon, 2002-08-12 at 20:34, Curt Sampson wrote:
> Ok, big bundled up reply here to various people.
>
> > From: Greg Copeland <[EMAIL PROTECTED]>
> >
> > > What makes things more confusing is poor understanding of a feature, not
> > > the feature itself.
> >
> > Agreed. Just because a feature ma
On Monday 12 August 2002 09:51 pm, Karl DeBisschop wrote:
> On Mon, 2002-08-12 at 21:28, Lamar Owen wrote:
> > I'm going to now go to the lagging plane -- building newer PostgreSQL for
> > older Red Hat (and maybe others, if I can get enough hard drives
> > available). The source RPM will still be
On Mon, 2002-08-12 at 18:41, Martijn van Oosterhout wrote:
> On Mon, Aug 12, 2002 at 11:30:36AM -0400, Andrew Sullivan wrote:
> > The problem is not just a system-level one, but a filesystem-level
> > one. Enabling 64 bits by default might be dangerous, because a DBA
> > might think "oh, it suppo
OK, seeing as no one voted, and only Tom and I objected originally, we
will keep the code as Thomas has applied it, namely that PGXLOG/-X is
recognized by initdb, postmaster, postgres, and pg_ctl. There is no
symlink from the /data directory to the WAL location.
Thomas, you mentioned implement
On Mon, 12 Aug 2002, Don Baccus wrote:
> It's a pity, as I pointed out the reduction in joins alone would really
> be great.
So implement the same thing relationally, and get your reduction
in joins. There are tricks, discussed on this very list in the
last few days, that would let you do what
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, seeing as no one voted, and only Tom and I objected originally, we
> will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> recognized by initdb, postmaster, postgres, and pg_ctl.
We will? It looks to me like Thomas lost the vote 2
I wanted to comment on this bitmapped index discussion because I am
hearing a lot about star joins, data warehousing, and bitmapped indexes
recently.
It seems we have several uses for bitmapped indexes:
Do index lookups in sequential heap order
Allow joining of bitmapped indexes
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, seeing as no one voted, and only Tom and I objected originally, we
> > will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> > recognized by initdb, postmaster, postgres, and pg_ctl.
>
> We will? It looks to me
On Tue, 13 Aug 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, seeing as no one voted, and only Tom and I objected originally, we
> > will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> > recognized by initdb, postmaster, postgres, and pg_ctl.
>
> We
On Mon, 2002-08-12 at 23:09, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, seeing as no one voted, and only Tom and I objected originally, we
> > will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> > recognized by initdb, postmaster, postgres, and pg_ctl.
On Tue, 13 Aug 2002, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > OK, seeing as no one voted, and only Tom and I objected originally, we
> > > will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> > > recognized by initdb, postmaster
On 12 Aug 2002, Greg Copeland wrote:
> You're constantly confusing Postgres' implementation with a "desired"
> implementation.
No. I'm still trying to figure out what the desired implementation
actually is. This is documented nowhere.
> If you're so keen on examples, please provide one that jus
On 13 Aug 2002, Greg Copeland wrote:
> On Mon, 2002-08-12 at 23:09, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > OK, seeing as no one voted, and only Tom and I objected originally, we
> > > will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> > > recogniz
Marc G. Fournier wrote:
> On Tue, 13 Aug 2002, Tom Lane wrote:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > OK, seeing as no one voted, and only Tom and I objected originally, we
> > > will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> > > recognized by initdb, postm
Marc G. Fournier wrote:
> > Well, you didn't vote again in my follow up email, so I thought you
> > didn't care anymore, and Thomas didn't reply to my email either. I am
> > clearly concerned, as you are, but Thomas isn't, and no one else seems
> > to care.
>
> k, why are you concerned? see my
Marc G. Fournier wrote:
> > I think Tom is on to something here. I meant to ask but never got
> > around to it. Why would anyone need to move the XLOG after you've
> > inited the db?
>
> I just determined that disk I/O is terrible, so want to move the XLOG over
> to a different file system that
On Tue, 2002-08-13 at 00:16, Marc G. Fournier wrote:
>
> Myself, if I'm going to move something around, it will be after the server
> has been running for a while and I've added in more drive space in order
> to correct a problem i didn't anticipate (namely, disk I/O) ... at that
> point, I reall
On Mon, 12 Aug 2002, Don Baccus wrote:
> Give it up. You're acting like a turkey. If you aren't, skin yourself
> a new non-turkey skin.
Since he appears not to be able to avoid abusive ad hominem attacks,
I'm now sending mail with "[EMAIL PROTECTED]" in the From: header
to /dev/null. If there'
On Tue, 2002-08-13 at 00:33, Curt Sampson wrote:
> On Mon, 12 Aug 2002, Don Baccus wrote:
>
> > Give it up. You're acting like a turkey. If you aren't, skin yourself
> > a new non-turkey skin.
>
> Since he appears not to be able to avoid abusive ad hominem attacks,
> I'm now sending mail with
On Tue, 2002-08-13 at 00:16, Curt Sampson wrote:
> I will revise my opinion the instant someone shows me something that I
> can't do relationally, or is easy to implement with inheritance, and
> difficult with relational methods. Now you know what you need to do, and
> if you have no example, we c
> If you move pg_xlog, you have to create a symlink in /data that points
> to the new location. Initdb would do that automatically, but if you
> move it after initdb, you would have to create the symlink yourself.
> With Thomas's current code, you would add/change PGXLOG instead to point
> to the
On 13 Aug 2002, Greg Copeland wrote:
> On Tue, 2002-08-13 at 00:16, Curt Sampson wrote:
> > I will revise my opinion the instant someone shows me something that I
> > can't do relationally, or is easy to implement with inheritance, and
> > difficult with relational methods. Now you know what you
On Tue, 2002-08-13 at 10:16, Curt Sampson wrote:
> On 12 Aug 2002, Greg Copeland wrote:
...
> > Are we then assuming that tuples in the child tables do not appear
> > > in the base table? That's more or less what I'd assumed when I
> > > originally heard about table inheritance (after all, instan
On Tue, 2002-08-13 at 09:25, Bruce Momjian wrote:
>
> There is a web page about "star joins" used a lot in data warehousing,
> where you don't know what queries are going to be required and what
> indexes to create:
>
> http://www.dbdomain.com/a100397.htm
>
> They show some sample queries
> Also, for Mario and Barry: does this test case look anything like what
> your real applications do? In particular, do you ever do a SELECT FOR
> UPDATE in a transaction that commits some changes, but does not update
> or delete the locked-for-update row? If not, it's possible there are
> yet
On Mon, Aug 12, 2002 at 09:38:00PM -0300, Marc G. Fournier wrote:
>
> should be fixed ... looks like just an ownership issue on a new directory
More like I uploaded that directory just as you were rsync'ing to
anonymous CVS and a lock file got copied along, but was never deleted
on a subsequent
Hello,
The attached patch adds CONVERSION stuff for cyrillic and
win874/1250/1251/1256 encodings.
Thank you.
From: Tatsuo Ishii <[EMAIL PROTECTED]>
Subject: [HACKERS] SQL99 CONVERT() function
Date: Tue, 06 Aug 2002 14:55:04 +0900 (JST)
Message-ID: <[EMAIL PROTECTED]>
> I have added SQL99's CON
> The attached patch adds CONVERSION stuff for cyrillic and
> win874/1250/1251/1256 encodings.
Thanks. I'll take care of this.
--
Tatsuo Ishii
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
84 matches
Mail list logo
