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" ...
> > >
>
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 D&D thing, and
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 th
"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 i
> 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:
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 abou
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
> > > 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 equivalants.
>
> Or are you saying that it's s
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 done.
I think this
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 equivalants.
Or ar
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 use a view:
>
> CREATE TABLE t1 (key
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Is it worth starting a thread about it at this stage? It
> is a pretty serious problem.
I agree, but given the lack of movement over the last couple years,
I'm not expecting a solution to suddenly emerge for 7.3 ...
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 use a view:
CREATE TABLE t1 (key serial, value1 text, value2 text);
> The issue here is (once again) that we're overloading type oid 0
> ("opaque") to mean too many different, incompatible things. I've
> ranted about this before and will not repeat my previous remarks.
> The bottom line is that we need to eliminate "opaque" in favor of
> a set of pseudo-datatypes
Curt Sampson wrote:
> The problem is, table inheritance is just syntatic sugar for creating
> separate tables, and a view that does a UNION SELECT on them all
> together, projecting only the common columns.
I've been wanting to point out that SQL views are really, when
scrutinized, "just syntac
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Is this a problem in that the functions are definined to return opaque (eg.
> PG_RETURN_VOID) but are then still usable in SELECT statements?
The issue here is (once again) that we're overloading type oid 0
("opaque") to mean too many differ
Yea, I added that TODO entry, and I am embarrased that a single cash_out
call could crash the backend. I thought about not making this public
knowledge, but making it public hasn't marshalled any forces to fix it
so maybe I was wrong to put it on TODO.
--
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> ... Anyway, who cares about printfs
> when stuff like select cash_out(2) is documented?
Well, they're two different issues. The cash_out problem is
intrinsically difficult to fix, and *will* break user-defined datatypes
when we fix it --- s
> It turns out to be a far more serious bug than that, and is not limited
> to cash_out. All these functions have the same problem:
>
> select proname from pg_proc where proargtypes=(select proargtypes from
> pg_proc where proname='cash_in') and pronargs=1 and proisstrict='t'
> order by proname;
I said:
> It turns out to be a far more serious bug than that, and is not limited
> to cash_out. All these functions have the same problem:
>
> With a few exceptions (the test(*) is long, as it requires one to wait for
> the database to start after testing each function, but there are 16 out
>
Hello:
I was investigating the bug about "select cash_out(2)" crashing the
backend. I thought fixing was a simple matter of checking whether some
argument to the function was NULL or not.
I added a NULL checking, but it obviously is not triggered, because the
data received is not NULL, but a no
> I see one unsubstantiated allegation about PG intermixed with a ton
> of content-free navel-gazing. Don't waste my time.
For instance, when I submitted patches for fulltextindex 7.2 it freely used
unchecked sprintf's everywhere. Even now I'm not sure what'll happen if a
malicious user really
On Mon, 12 Aug 2002, Justin Clift wrote:
> Hi everyone,
>
> Whilst looking around for some more PostgreSQL related stuff, this
> message turned up:
>
> http://mail.wirex.com/pipermail/sardonix/2002-February/51.html
>
> The interesting bit is in an email messages included about halfway
> do
Justin Clift <[EMAIL PROTECTED]> writes:
> Whilst looking around for some more PostgreSQL related stuff, this
> message turned up:
> http://mail.wirex.com/pipermail/sardonix/2002-February/51.html
I see one unsubstantiated allegation about PG intermixed with a ton
of content-free navel-gazing.
Hi everyone,
Whilst looking around for some more PostgreSQL related stuff, this
message turned up:
http://mail.wirex.com/pipermail/sardonix/2002-February/51.html
The interesting bit is in an email messages included about halfway
down. It speaks of Bad Things in the PostgreSQL source code a
> So my initial thinking is that this is a profound problem. But after a little
> more thought, I can make the question_id field of the question table be a
> SERIAL type and the primary key. That way, when I insert rows into either
> the position question or the binary question table, it will be
On Mon, 12 Aug 2002, Justin Clift wrote:
> Hi Chris,
>
> Christopher Kings-Lynne wrote:
> >
>
> > Still, I believe this should require a 7.2.2 release. Imagine a university
> > database server for a course for example - the students would just crash it
> > all the time.
>
> Hey yep, good po
> 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 a
> "no known vulnerabilities" rel
Hi Chris,
Christopher Kings-Lynne wrote:
>
> Still, I believe this should require a 7.2.2 release. Imagine a university
> database server for a course for example - the students would just crash it
> all the time.
Hey yep, good point.
Is this the only way that we know of non postgresql-supe
> 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 that looks like a
> re
> 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 scripts. The third patch addresses
> issues generated by the i
> Now, in the multibyte case, again in textlen(), I see:
>
>/* optimization for single byte encoding */
>if (pg_database_encoding_max_length() <= 1)
> PG_RETURN_INT32(VARSIZE(t) - VARHDRSZ);
>
>PG_RETURN_INT32(
>pg_mbstrlen_with_len(VARDATA(t), VARSIZE(t) - VARHDRSZ));
>
On Sun, 11 Aug 2002, Don Baccus wrote:
> It's just type extensibility, really.
Yeah.
> As to why, again there's an efficiency argument, as I said earlier some
> joins can be avoided given PG's implementation of this feature:
> [TI and relational examples deleted]
What you gave is not the relat
Curt Sampson wrote:
> The last question comes up because, during the conversation up to this
> point, we seem to have implicitly accepted that table inheritance is
> an "object-oriented" way of doing things. Thinking further on this,
> however, I've decided that it's not in fact object-oriented a
On Thu, 8 Aug 2002, Jordan Henderson wrote:
> I think what would be useful is to discuss the theory part.
As do I.
> - Date has 3, however his most current work is dated 2000, The Third
> Manifesto SECOND EDITION.
This is actually Date and Darwen.
I think we should also add Date's _An Introdu
Tom Lane dijo:
> CVSROOT: /cvsroot
> Module name: pgsql-server
> Changes by: [EMAIL PROTECTED] 02/08/11 17:17:35
>
> Log message:
> Code review of CLUSTER patch. Clean up problems with relcache getting
> confused, toasted data getting lost, etc.
Whoa. That's a whole
Rod Taylor <[EMAIL PROTECTED]> writes:
> However, I have to wonder why GetDefaultOpClass doesn't simply use the
> first Binary Compatible opclass.
Because that would completely destroy the point of having multiple
opclasses for a datatype: you'd only do so if they *act different*.
Therefore, havi
Appears there is a problem finding the opclass when indexing a domain.
CREATE DOMAIN newint as int4;
CREATE TABLE tab (col newint unique);
ERROR: data type newint has no default operator class for access method
"btree"
You must specify an operator class for the index or define a
Tatsuo Ishii wrote:
>>Any objection if I rework this function to meet SQL92 and fix the bug?
> I don't object.
One more question on this: how can I generate some characters with > 1
encoding length? I need a way to test the work I'm doing, and I'm not
quite sure how to test it.
Just making a
OK, great to have people reviewing them. I will hold on all the python
patches until I hear back from Christopher:
http://candle.pha.pa.us/cgi-bin/pgpatches
---
Greg Copeland wrote:
Checking application/pgp-sign
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 to agree with Peter: it should not
be par
Hi Florian,
Very hard call.
If this was even a "fringe case" whereby even only a few places that are
doing "the right thing" would be compromisable, then we should probably
go for a 7.2.2. Even if it's only 7.2.1 with this one bug fix.
However, it sounds like this bug is really only going to a
We still haven't really decided what to do about libpqxx. The only
argument I've heard so far against distributing it separately is that it
would induce users to use libpq++ instead. I think having both libraries
in the distribution is going to be even more confusing, especially since
one is "ol
Justin Clift <[EMAIL PROTECTED]> writes:
> - 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?
> So, a web application layer can request a date from a user, do standard
> integrity checks (like looking for w
Tatsuo Ishii wrote:
>>Any objection if I rework this function to meet SQL92 and fix the bug?
>
I've started working on text_substr() as described in this thread (which
is hopefully prep work for the replace() function that started the
thread). I haven't really looked at toast or multibyte clo
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 that looks like a
reasonable dat
Hi Florian,
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?
So, a web application layer can request a date from a user, do standard
integrity checks (like looking for weird
Michael Meskes <[EMAIL PROTECTED]> writes:
> On Tue, Jul 30, 2002 at 11:50:38PM -0400, Bruce Momjian wrote:
>> ecpg and bison issues - solved?
> Not solved yet. And it's just a matter of time until we run into it with
> the main parser grammar file as well.
Yeah, I've been worrying about that to
Justin Clift <[EMAIL PROTECTED]> writes:
> Is it possible to crash a 7.2.1 backend without having an entry in the
> pg_hba.conf file?
No, but think of web applications and things like that. The web
frontend might pass in a date string which crashes the server backend.
Since the crash can be tri
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 scripts. The third patch addresses
issues generated by the implicate to
Christopher Kings-Lynne wrote:
> unique_oids script
Look in src/include/catalog. You'll find duplicate_oids & unused_oids
shell scripts.
Joe
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Tue, Jul 30, 2002 at 11:50:38PM -0400, Bruce Momjian wrote:
> ecpg and bison issues - solved?
Not solved yet. And it's just a matter of time until we run into it with
the main parser grammar file as well. Bison upstream is working on
removing all those short ints, but I have yet to receive a v
I wouldn't apply this _just_ yet Bruce as I'm not certain all the changes
are necessary... I intend to look into it but I haven't had the time yet
(sorry Greg!)
Chris
On Sun, 11 Aug 2002, Bruce Momjian wrote:
>
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
>
> > NAMEDATALEN will be 64 or 128 in 7.3. At this point, we better decide
> > which one we prefer.
> >
> > The conservative approach would be to go for 64 and perhaps increase it
> > again in 7.4 after we get feedback and real-world usage. If we go to
> > 128, we will have trouble decreasing it
> Joe Conway <[EMAIL PROTECTED]> writes:
> > I guess I should know better than to jump to a conclusion. But I *was*
> > under the impression we were supposed to use the unused_oids script to
> > get a unique oid for a new function.
unique_oids script
Chris
---(end
55 matches
Mail list logo
