Try 'public','s1' perhaps...
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tatsuo Ishii
Sent: Monday, 19 August 2002 2:31 PM
To: [EMAIL PROTECTED]
Subject: [HACKERS] set search_path failure
I'm seeing this:
test=# create schema s1;
Try 'public','s1' perhaps...
Wao, this is confusing:-)
The man page says:
SET variable { TO | = } { value | 'value' | DEFAULT }
And:
test=# show search_path;
search_path
-
public, s1
(1 row)
So user naturally thinks
set search_path to 'public,s1';
is a correct
On Sun, 18 Aug 2002, Joe Conway wrote:
Philip Warner wrote:
So the obvious question is - in the opinion of people who know the code,
can a function-result-cache be implemented with a lifetime of a single
statement, without butchering the function manager?
I don't know if I fully
What Philip seems to be asking for is a mechanism where by if a function
is marked as being mathematically deterministic (given a particular set of
parameters the same result is always returned -- eg: cos(), sin(),
etc) then the result is cached and next time the function is called with
the
At 17:03 19/08/2002 +1000, Gavin Sherry wrote:
What Philip seems to be asking for is a mechanism where by if a function
is marked as being mathematically deterministic (given a particular set of
parameters the same result is always returned -- eg: cos(), sin(),
etc) then the result is cached and
What Philip seems to be asking for is a mechanism where by if a function
is marked as being mathematically deterministic (given a
particular set of
parameters the same result is always returned -- eg: cos(), sin(),
etc) then the result is cached and next time the function is called with
the
At 15:41 19/08/2002 +0800, Christopher Kings-Lynne wrote:
So it seems Philip already has what he wants?
I really hope so, but my understanding is that this information is used
during optimization, not execution; I want it to be used in execution.
I'd have thought that if a matching user couldn't be found in the
specified database then it would default to searching through the
global users? Would be more intuitive...
Lee.
Bruce Momjian writes:
Sample run:
$ psql -U postgres test
psql: FATAL: user postgres@test does not
Having contributed to the need for pg_dump/initdb/restore when
upgrading from 7.2 to 7.3, I plan to submit a patch which *could* make
future transitions easier.
bufpage.h:
typedef struct PageHeaderData
{
...
uint32 pd_type;/* kind and version */
...
}
#define
Seems with above you are not able to constrain what qualifies for a
supertable row, you would only be able to specify constraints that
apply to all it's subtables.
Yes, that's the whole point. If I have a constraint on a table, I think
it should *never* be possible for that constraint
Philip Warner [EMAIL PROTECTED] writes:
My theory is that if such a piece of code gets a performance gain, then the
code is probably worth including, assuming that the function manager does
not need to be butchered to achieve the desired goal. Does that sound
reasonable?
Some real results
Tatsuo Ishii [EMAIL PROTECTED] writes:
The man page says:
SET variable { TO | = } { value | 'value' | DEFAULT }
So user naturally thinks
set search_path to 'public,s1';
is a correct syntax, no?
The man page needs improvement --- some variables accept a list of
values now. In
On Mon, 19 Aug 2002, Zeugswetter Andreas SB SD wrote:
Yes, that's the whole point. If I have a constraint on a table, I think
it should *never* be possible for that constraint to be violated. If a
subtable should not have constraint the supertable has, it shouldn't
inherit from the
Manfred Koizar [EMAIL PROTECTED] writes:
Having contributed to the need for pg_dump/initdb/restore when
upgrading from 7.2 to 7.3, I plan to submit a patch which *could* make
future transitions easier.
We do need a page version code but I do not want to waste 4 bytes per
page on it.
I was
Yes, that's the whole point. If I have a constraint on a table, I think
it should *never* be possible for that constraint to be violated. If a
subtable should not have constraint the supertable has, it shouldn't
inherit from the supertable.
If you want that, you simply need to
Philip Warner [EMAIL PROTECTED] writes:
At 15:41 19/08/2002 +0800, Christopher Kings-Lynne wrote:
So it seems Philip already has what he wants?
I really hope so, but my understanding is that this information is used
during optimization, not execution; I want it to be used in execution.
On Mon, 19 Aug 2002, Zeugswetter Andreas SB SD wrote:
So what you're saying is that constraints shouldn't be inherited?
No. I even said that inheriting should be the default.
Ah. So you think it should be possible not to inherit constraints.
A local constraint should be made obvious from
On Mon, 2002-08-19 at 15:42, Curt Sampson wrote:
A local constraint should be made obvious from looking at the schema,
Ok, this now I could live with. Though I'm not sure that its
theoretically very defensible, or worth the effort. Other languages
that offer constraints, such as Eiffel
On Mon, 2002-08-19 at 09:42, Curt Sampson wrote:
On Mon, 19 Aug 2002, Zeugswetter Andreas SB SD wrote:
So what you're saying is that constraints shouldn't be inherited?
No. I even said that inheriting should be the default.
Ah. So you think it should be possible not to inherit
Hi Guys,
It would be really neat if the contrib makefile could run an sql script upon
uninstall as well as removing the files. Is that a neat idea? Means it can
get rid off all the functions, types, etc. automatically.
Unfortunately it's a bit beyond my meagre Makefile abilities...
Chris
Since there didn't seem to be anyone objecting to the notion of
decoupling UNIQUE from SERIAL, I'm going to go ahead with
reviewing/applying Rod's recent patch that does that (and fixes pg_dump
to dump 7.3 serials correctly). We can continue to debate about
the merits of making additional
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
It would be really neat if the contrib makefile could run an sql script upon
uninstall as well as removing the files. Is that a neat idea? Means it can
get rid off all the functions, types, etc. automatically.
Automatically? How will it
Automatically? How will it determine which database(s) contain the
types? What if the databases require password access?
It probably would be useful to supply an uninstall SQL script to reverse
the effects of the install script, but since we have no idea where the
install was run I think
Surprised it took this long.
Vince.
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
http://www.camping-usa.com
Hi Vince,
Glad he made the advisory for something there's a fix for. :)
Regards and best wishes,
Justin Clift
Vince Vielhaber wrote:
Surprised it took this long.
Vince.
--
==
Vince Vielhaber -- KA8CSHemail:
Alvar Freude [EMAIL PROTECTED] writes:
What about checking the input for backslash, quote,
and double quote (\')? If you are not taking care of those in input
then crashing the backend is going to be the least of your worries.
with Perl and *using placeholders and bind values*, the
Hi Florian,
You guys *definitely* write scarey code.
:-(
Regards and best wishes,
Justin Clift
Florian Weimer wrote:
Alvar Freude [EMAIL PROTECTED] writes:
What about checking the input for backslash, quote,
and double quote (\')? If you are not taking care of those in input
Justin Clift [EMAIL PROTECTED] writes:
You guys *definitely* write scarey code.
Yes, indeed. My code has a lot of unnecessary and error-prone input
validation checks because I don't trust the PostgreSQL parser.
That's scary. You don't trust your database that it processes a
simple text
On Mon, 2002-08-19 at 13:14, Florian Weimer wrote:
Justin Clift [EMAIL PROTECTED] writes:
You guys *definitely* write scarey code.
Yes, indeed. My code has a lot of unnecessary and error-prone input
validation checks because I don't trust the PostgreSQL parser.
Bah.. Check the datatype
OK, with two people now asking to have the patch removed, and with no
comment from Thomas, I have removed the patch. This removes XLogDir
environment variable, and -X postmaster/postgres/initdb/pg_ctl flag.
I have also removed the code that dynamically sized xlogdir.
... Back in town...
Justin Clift [EMAIL PROTECTED] writes:
Glad he made the advisory for something there's a fix for. :)
The claim that this bug allows execution of arbitrary code is bogus anyway.
The overflow at INT_MIN will clobber the stack, yes, but in an absolutely
predetermined way; an attacker will have no
Florian Weimer [EMAIL PROTECTED] writes:
That's the idea. It's the job of the database to guarantee data
integrety.
Obviously, the PostgreSQL developers disagree.
Look: it's an acknowledged bug and it's fixed in current sources.
The disagreement is over whether this single bug is sufficient
Tom Lane [EMAIL PROTECTED] writes:
Saying or implying that the developers don't care about data integrity
does not enhance your credibility.
Sorry, my fault. Indeed, I didn't check carefully whether the people
who go a bit too far in downplaying the problem at hand are in fact
PostgreSQL
Thomas Swan [EMAIL PROTECTED] writes:
1. create a user with createdb privilege.
2. create a database as that user (allowing that user full reign over
that particular db)
3. drop the createdb from the user.
4. pg_dumpall the databases to a single file
5. either use pg_restore or psql infile
Neil Conway wrote:
Thomas Swan [EMAIL PROTECTED] writes:
1. create a user with createdb privilege.
2. create a database as that user (allowing that user full reign over
that particular db)
3. drop the createdb from the user.
4. pg_dumpall the databases to a single file
5. either
foobar
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
CREATE CAST WITHOUT FUNCTION is capable of creating binary equivalences
that will crash the backend when used (eg, between pass-by-value and
pass-by-reference datatypes). The existing restriction that you must
own one of the datatypes hardly seems like an adequate permissions
check ...
[EMAIL PROTECTED] (Florian Weimer) wrote
Alvar Freude [EMAIL PROTECTED] writes:
What about checking the input for backslash, quote,
and double quote (\')? If you are not taking care of those in
input then crashing the backend is going to be the least of your
worries.
with Perl and
On Sat, Aug 17, 2002 at 11:08:45PM -0400, Bruce Momjian wrote:
integrate or move to gborg libpqxx, Pg:DBD
It's no longer my CVS home tree... Is there something I can/should
do for this?
Jeroen
---(end of broadcast)---
TIP 1: subscribe and
Vince,
Do you reckon it's worth you responding to Sir Mordred and pointing
out that he overstated the vulnerability?
:-)
Regards and best wishes,
Justin Clift
Tom Lane wrote:
Justin Clift [EMAIL PROTECTED] writes:
Glad he made the advisory for something there's a fix for. :)
The
On Tue, 20 Aug 2002, Justin Clift wrote:
Vince,
Do you reckon it's worth you responding to Sir Mordred and pointing
out that he overstated the vulnerability?
Not me. Tom (pref) or Marc would be the proper respondent.
:-)
Regards and best wishes,
Justin Clift
Tom Lane wrote:
Actually, I think Jeroen T. Vermeulen [EMAIL PROTECTED] should create the
project. It is his code, and if he would add me as an admin, that would
help. I am CC'ing him.
---
Marc G. Fournier wrote:
On Sun, 18 Aug 2002,
Joe Conway wrote:
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I agree 100%. If you want an index, unique constraint, or primary key on
a SERIAL, I think you should explicitly add it. SERIAL should give me a
column that automatically increments -- no more, no less.
Hmm, do
On Tue, 20 Aug 2002, Justin Clift wrote:
Vince,
Do you reckon it's worth you responding to Sir Mordred and pointing
out that he overstated the vulnerability?
Not me. Tom (pref) or Marc would be the proper respondent.
Has it actually been fixed?
Chris
Christopher Kings-Lynne wrote:
On Tue, 20 Aug 2002, Justin Clift wrote:
Vince,
Do you reckon it's worth you responding to Sir Mordred and pointing
out that he overstated the vulnerability?
Not me. Tom (pref) or Marc would be the proper respondent.
Has it actually been
I didn't follow the index part completely, but will heap and index pages
have the version info in the same offset? Will there be a way to
easily identify an index page vs. a heap page.
---
Tom Lane wrote:
Manfred Koizar
Yes, perhaps a bad precedent. I have very rarely done this. I do have
the patch here if anyone wants to use it. My guess is if someone
implements it, it will be done only in initdb, and use symlinks, which
you and Marc don't like, so we may be best leaving it undone for 7.3 and
returning with
Vince Vielhaber wrote:
Surprised it took this long.
Yes, me too, and it says the solution is to upgrade to 7.2.1. Nope.
-- Forwarded message --
Date: Mon, 19 Aug 2002 15:40:28 +
From: Sir Mordred The Traitor [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: @(#)
Justin Clift wrote:
Hi Vince,
Glad he made the advisory for something there's a fix for. :)
Oh, I see he jumpe on cash_words() and didn't mention cash_out.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Has it actually been fixed?
I couldn't reproduce a problem with his example. The buffer size in
cash_words is awfully tight though --- it's dimensioned 128 which looks
like a round number rather than a carefully calculated one, and the
required
Justin Clift wrote:
Christopher Kings-Lynne wrote:
On Tue, 20 Aug 2002, Justin Clift wrote:
Vince,
Do you reckon it's worth you responding to Sir Mordred and pointing
out that he overstated the vulnerability?
Not me. Tom (pref) or Marc would be the proper
Bruce Momjian [EMAIL PROTECTED] writes:
I didn't follow the index part completely, but will heap and index pages
have the version info in the same offset?
Sure, low byte of pd_pagesize.
Will there be a way to easily identify an index page vs. a heap page.
There already is: heap pages have
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 we do something about
subdividing type
Thomas Lockhart [EMAIL PROTECTED] writes:
Sorry to hear that this is the way it turned out. It is a bad precedent
imho, and I see no way forward on my interest in this area. Hopefully
someone else will pick it up; perhaps one of those so vehemently against
the details of this?
I said I would
Oh, sorry. I will do it now.
---
Marc G. Fournier wrote:
We're talking about libpq++, not libpqxx :)
On Mon, 19 Aug 2002, Bruce Momjian wrote:
Actually, I think Jeroen T. Vermeulen [EMAIL PROTECTED] should
On Mon, 19 Aug 2002, Bruce Momjian wrote:
Joe Conway wrote:
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I agree 100%. If you want an index, unique constraint, or primary key on
a SERIAL, I think you should explicitly add it. SERIAL should give me a
column that automatically
Done. Called libpq++.
---
Bruce Momjian wrote:
Oh, sorry. I will do it now.
---
Marc G. Fournier wrote:
We're talking about libpq++,
Justin Clift [EMAIL PROTECTED] writes:
Hang on, you seem to be suggesting we release a major new upgrade, with
major new functionality, knowing it contains a way to trivially crash
the backend.
This particular hole has been in *every* release since Postgres 1.01.
I'm really not interested in
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
test= select cash_words('-70');
Minus twenty one million four hundred seventy four thousand eight
hundred thirty six dollars and forty eight cents
It doesn't crash - but it sure is giving the wrong answer ;)
Well,
I'd like to see something done about this fairly soon, but it's not
happening for 7.3 ...
Hang on, you seem to be suggesting we release a major new upgrade, with
major new functionality, knowing it contains a way to trivially crash
the backend.
Err.. hang on. What happened to our
On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
I'd like to see something done about this fairly soon, but it's not
happening for 7.3 ...
Hang on, you seem to be suggesting we release a major new upgrade, with
major new functionality, knowing it contains a way to trivially
Justin Clift [EMAIL PROTECTED] writes:
Tom Lane wrote:
This particular hole has been in *every* release since Postgres 1.01.
How many releases have we known about this and still done a major
release?
Several; a quick glance in the archives shows this has been on the TODO
list since
Rod Taylor dijo:
The simple fix is to drop the money type entirely as it serves few
purposes -- but there are some who use it.
There are a lot of other functions that cause the same problem. Just
dropping or fixing cash_out is not the solution.
--
Alvaro Herrera (alvherre[a]atentus.com)
Revert. The XLogDir change was incomplete and basically useless to
start with ...
Yea, but it was tied into the PGXLOG commit. Thomas, what are we doing
with that?
Why ask me?
- Thomas
---(end of broadcast)---
TIP 4:
On Tue, 20 Aug 2002 13:40, Justin Clift wrote:
[snip]
For example, thinking about something like the various ISP's around who
host PostgreSQL databases; how much effort would it take to fix the
vulnerabilities that let someone with remote access, but no ability to
run a trusted language, take
Hi Mark,
Mark Pritchard wrote:
snip
I believe its been said before, in this forum no less, that PostgreSQL should
focus on its primary role as an RDBMS and not be paranoid about security. I
believe it was the thread on SSL connections, and Tom suggested a simple ssh
tunnel or vpn.
Of
Mark Pritchard [EMAIL PROTECTED] writes:
I believe its been said before, in this forum no less, that
PostgreSQL should focus on its primary role as an RDBMS and not be
paranoid about security. I believe it was the thread on SSL
connections, and Tom suggested a simple ssh tunnel or vpn.
I'd
As Tom pointed out, we've already had several releases without getting
rid of this OPAQUE DOS bug, and as pointed out he also really doesn't
have the patience for fixing it (yet).
Was hoping we could get serious bugs fixed sooner rather than later,
otherwise I'm afraid of us just adding
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 10:22 PM
To: Mark Pritchard
Cc: Justin Clift; Tom Lane; Christopher Kings-Lynne;
[EMAIL PROTECTED]
Subject: Re: [HACKERS] @(#) Mordred Labs advisory 0x0001:
Buffer overflow in
The 'type_sanity' and 'domain' regression tests seem to fail with CVS
HEAD. Here's the diff:
*** ./expected/type_sanity.out Sun Aug 4 15:48:11 2002
--- ./results/type_sanity.out Tue Aug 20 01:32:35 2002
***
*** 16,22
SELECT p1.oid, p1.typname
FROM pg_type as p1
WHERE
Dann Corbit [EMAIL PROTECTED] writes:
If you *know* of a buffer overrun, and simply decide not to fix it,
that sounds very negligent to me.
*sigh*, no one is doing that, and it is pure negligence on your part
for replying to a thread that you clearly have not read.
Cheers,
Neil
--
Neil
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 10:42 PM
To: Dann Corbit
Cc: Neil Conway; Mark Pritchard; Justin Clift; Tom Lane;
Christopher Kings-Lynne; [EMAIL PROTECTED]
Subject: Re: [HACKERS] @(#) Mordred Labs advisory 0x0001:
Dann Corbit [EMAIL PROTECTED] writes:
I read (in some other message) that this buffer overrun problem has been
known for a very, very long time.
No, the problem you're referring to (cash_out() and friends) is *not*
a buffer overrun.
Cheers,
Neil
--
Neil Conway [EMAIL PROTECTED] || PGP Key
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 10:48 PM
To: Dann Corbit
Cc: Neil Conway; Mark Pritchard; Justin Clift; Tom Lane;
Christopher Kings-Lynne; [EMAIL PROTECTED]
Subject: Re: [HACKERS] @(#) Mordred Labs advisory 0x0001:
To simply decide not to fix it means:
snip
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
75 matches
Mail list logo
