Curt Sampson wrote:
On Sun, 11 Aug 2002, Don Baccus wrote:
Oh? Ok, please translate the following into equivalant SQL that
does not use a view:
...
Granulize GRANT to the table column level.
Can you please show me the code for that? After all, I showed you
all of my code when doing
Tom Lane wrote:
Curt Sampson [EMAIL PROTECTED] writes:
On Sun, 11 Aug 2002, Don Baccus wrote:
Granulize GRANT to the table column level.
Can you please show me the code for that?
It's required by the SQL spec. PG hasn't got it, but the spec is
perfectly clear about how it should be
I've just finished a quick grep through the backend sources for
sprintf, and identified the following files as containing possible
problems:
src/backend/port/dynloader/freebsd.c
This one is perhaps dodgy. You ahve this:
static char error_message[BUFSIZ];
Then you have this:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
src/backend/port/dynloader/freebsd.c
This one is perhaps dodgy. You ahve this:
static char error_message[BUFSIZ];
Then you have this:
sprintf(error_message, dlopen (%s) not supported, file);
Where file isn't restricted in length I
Am Montag, 12. August 2002 08:02 schrieb Don Baccus:
Curt Sampson wrote:
On Sun, 11 Aug 2002, Don Baccus wrote:
I've been wanting to point out that SQL views are really, when
scrutinized, just syntactic sugar ...
Oh? Ok, please translate the following into equivalant SQL that
does not
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 get rid of SQL, we can go all
the way with the DD thing, and
On Mon, 2002-08-12 at 11:38, Mario Weilguni wrote:
Am Montag, 12. August 2002 08:02 schrieb Don Baccus:
Curt Sampson wrote:
On Sun, 11 Aug 2002, Don Baccus wrote:
I've been wanting to point out that SQL views are really, when
scrutinized, just syntactic sugar ...
Oh? Ok, please
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 sure we have
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 get rid
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 this?)
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, so anything
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_class e,
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;
' LANGUAGE
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 date is
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 if
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
is
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 regular expression in
Just go with tradition and label all of your variables with a
v_varname. 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
-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 Sherry
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) is
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 pour
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.
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 program
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
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 is
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 filesystem
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.
I do
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)
)
This
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.
If
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 means,
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).
This (and
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 distinction has
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 ...,
CONSTRAINT No data
[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 backend.
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, I have
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
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
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
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 another bit
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 you
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 python
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 problem.
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
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
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 directory
[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). Let me
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 on
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 is
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 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 may not be well
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 supports
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
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
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
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 like
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 will? It
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.
We
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, postgres,
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
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
recognized by initdb,
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, postmaster,
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 other
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 is
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 really
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's a
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 [EMAIL
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 can
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 new
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 need
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, instantiating
82 matches
Mail list logo
