Patch applied. Thanks.
---
Oliver Elphick wrote:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
-Forwarded Message-
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL
Tatsuo Ishii [EMAIL PROTECTED] writes:
PQescapebytea() is not multibyte aware and will produce bad multibyte
character sequences. Example:
I think 0x89 should be converted to '\\211' since 0x89 of 0x8950 is
considered as non printable characters.
Hmm, so essentially we'd have to convert all
Hi everyone,
For anyone who's interested in the patent status of UB-Tree's, here is
further info.
:-)
Regards and best wishes,
Justin Clift
Original Message
Subject: AW: UB-Tree's and patents
Date: Thu, 4 Apr 2002 17:41:10 +0200
From: Rudolf Bayer [EMAIL PROTECTED]
To:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Hmm. Seems like that case, and the various ones involving adjustment of
char/varchar length by hacking atttypmod, would be useful to support via
ALTER COLUMN even if we don't have a full implementation. Essentially
this would be taking the
Thomas Lockhart [EMAIL PROTECTED] writes:
istm that the general strategy for changing column types would require
marking a column as dead and adding a new column to replace it, or
writing an atomic copy / modify / replace operation for tables which
modifies tuples as it proceeds, or ?? Just
On Thu, 4 Apr 2002, Bruce Momjian wrote:
It that acceptable to the JDBC folks? It requires two SET timeout = 0
statements, one after the statement in the transaction, and another
after the transaction COMMIT WORK.
That's fine, though probably about as much work as just implementing the
On Sat, 6 Apr 2002, Justin Clift wrote:
Hi everyone,
For anyone who's interested in the patent status of UB-Tree's, here is
further info.
:-)
I dont' understand that. Does it means someone has no rights to
implement the algorithm in any form ? Who has patented an idea of
relational
Tom Lane wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
PQescapebytea() is not multibyte aware and will produce bad multibyte
character sequences. Example:
I think 0x89 should be converted to '\\211' since 0x89 of 0x8950 is
considered as non printable characters.
Hmm, so essentially we'd
-Original Message-
From: Doug McNaught [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 11:30 AM
To: Dann Corbit
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
Dann Corbit [EMAIL PROTECTED] writes:
It would be nice if total table cardinality could be
Jan Wieck [EMAIL PROTECTED] writes:
Could we get out of this by defining that timeout is
automatically reset at next statement end?
I was hoping to avoid that, because it seems like a wart. OTOH,
it'd be less of a wart than the global changes of semantics that
Bruce is
Joe Conway [EMAIL PROTECTED] writes:
But the error comes from pg_verifymbstr. Since bytea has no encoding
(it's just an array of bytes afterall), why does pg_verifymbstr get
applied at all to bytea data?
Because textin() is used for the initial conversion to an unknown
constant --- see
Christopher Kings-Lynne wrote:
I really don't buy this argument; it seems exactly comparable to
arguing that the notion of current directory in Unix is evil, and
that users should be forced to specify absolute paths to every
file that they reference.
You know, I'm kinda surprised
Hiroshi Inoue wrote:
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
I don't object to use a search path to resolve unqualified
function, type etc names. But it is very siginificant for
users to be able to be sure what tables they are handling.
I really don't buy this
Hi Oleg,
My understanding of patent law (in a generalised way) means that for any
country in which you're granted a patent on something, these days it
effectively means you've got control of the usage of that particular
thing.
So, if Prof. Rudolf Bayer has a patent on the algorithm for
Fernando Nasser [EMAIL PROTECTED] writes:
Christopher Kings-Lynne wrote:
You know, I'm kinda surprised that the spec doesn't define a CURRENT_SCHEMA
variable you can query???
Maybe because it would be the same as CURRENT_USER.
It'd probably make sense for us to have one, though, given that
Tom Lane wrote:
INSERT INTO t1(bytea_col) VALUES('characters produced by
PQescapebytea'::bytea);
Probably that would cause the error to disappear, but it's hardly a
desirable answer.
I wonder whether this says that TEXT is not a good implementation of
type UNKNOWN. That choice was made
Joe Conway [EMAIL PROTECTED] writes:
I could take a look at this. Any guidance other than faithfully
preserving the contents of a C string?
Take textin/textout, remove multibyte awareness? Actually the hard
part is to figure out which of the existing hardwired calls of textin
and textout
Tom Lane wrote:
OTOH, I was surprised to read your message because I had assumed the
damage was being done much further upstream, viz during collection of
the query string by pq_getstr(). Do we need to think twice about that
processing, as well?
I just looked in pq_getstr() I see:
Joe Conway [EMAIL PROTECTED] writes:
I think you're correct that in a client/database encoding mismatch
scenario, there would be bigger problems. Thoughts on this?
This scenario is probably why Tatsuo wants PQescapeBytea to octalize
everything with the high bit set; I'm not sure there's any
Jan Wieck [EMAIL PROTECTED] writes:
If at all, SET commands should behave like everything else.
If done inside a transaction, they have to rollback.
I have thought of a scenario that may be sufficient to justify fixing
SETs to roll back on transaction abort. Consider
BEGIN;
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Could we get out of this by defining that timeout is
automatically reset at next statement end?
I was hoping to avoid that, because it seems like a wart. OTOH,
it'd be less of a wart than the global changes of semantics
Dann Corbit [EMAIL PROTECTED] writes:
It would be nice if total table cardinality could be maintained live.
So (after the initial vacuum) we update the cardinality for each table
in the system table (or perhaps add an entry to the table itself).
There are two reasons why this is an important
It would be nice if total table cardinality could be maintained live.
How would this work with MVCC?
It wouldn't. That's why it's not there. Under MVCC, table cardinality
is in the eye of the beholder...
That makes me curious how oracle implements it. I was under the impression
that
I don't think your idea would work for a concurrent user setup where
people have different transactions started at different times with
different amounts of changes inside each transaction.
That's why it would have to be tracked on a per connection basis for
all the tables.
I tried it out
Peter Bierman [EMAIL PROTECTED] writes:
... Your comment: An
accurate cardinality figure can greatly enhance the optimizer's
ability to perform joins in the correct order was intriguing, and I'd
be interested in Tom's thoughts on just that bit.
Approximate figures are quite sufficient for
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 3:42 PM
To: Peter Bierman
Cc: Dann Corbit; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
Peter Bierman [EMAIL PROTECTED] writes:
... Your comment: An
accurate cardinality
Doug McNaught [EMAIL PROTECTED] writes:
Dann Corbit [EMAIL PROTECTED] writes:
It would be nice if total table cardinality could be maintained live.
How would this work with MVCC?
It wouldn't. That's why it's not there. Under MVCC, table cardinality
is in the eye of the beholder...
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 11:37 AM
To: Doug McNaught
Cc: Dann Corbit; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
Doug McNaught [EMAIL PROTECTED] writes:
Dann Corbit [EMAIL PROTECTED] writes:
It
Dann Corbit [EMAIL PROTECTED] writes:
How many accounts are 90 days overdue? Bill says 78 and Frank says 82.
Who is right and how can we know?
If Bill and Frank look at exactly the same instant (ie, from read-only
transactions started at the same time), they will get the same answer.
If they
Dann Corbit [EMAIL PROTECTED] writes:
If this is true (even after a commit) then MVCC is a very bad thing. No
transactions occur, and two people ask the same question yet get
different answers. Doesn't that scare anyone? That would mean (among
other things) that Postgresql cannot be used
Hmm, so essentially we'd have to convert all codes = 0x80 to prevent
them from being mistaken for parts of multibyte sequences?
Yes.
Ugh, but
you're probably right. It looks to me like byteaout does the reverse
already.
As for the new UNKNOWN data type, that seems a good thing for
me.
Dann Corbit [EMAIL PROTECTED] writes:
How would this work with MVCC?
Whenever a commit occurs, the pending inserts are totaled into the sum
and the pending deletes are subtracted. It can be a list in memory or
whatever. Maybe you are referring to the old (expired) rows begin
stored
-Original Message-
From: Doug McNaught [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 11:55 AM
To: Dann Corbit
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
Dann Corbit [EMAIL PROTECTED] writes:
How would this work with MVCC?
Whenever a commit
Dann Corbit [EMAIL PROTECTED] writes:
At any rate, there is clearly a concept of cardinality in any case.
Certainly. The count(*) value is perfectly well defined within any one
transaction. We *could*, if we wanted to, implement bookkeeping logic
that would keep track of the number of rows
Not to mention it only increases the speed of:
SELECT count(*) FROM foo;
and not:
SELECT count(*) FROM foo WHERE bar;
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are
-Original Message-
From: Jon Grov [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 12:54 PM
To: Dann Corbit
Cc: Mike Mascari; Doug McNaught; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
Dann Corbit [EMAIL PROTECTED] writes:
That's interesting. If Oracle
-Original Message-
From: Rod Taylor [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 12:35 PM
To: Dann Corbit; Tom Lane
Cc: Doug McNaught; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
Not to mention it only increases the speed of:
SELECT count(*) FROM
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I think you're correct that in a client/database encoding mismatch
scenario, there would be bigger problems. Thoughts on this?
This scenario is probably why Tatsuo wants PQescapeBytea to octalize
everything with the high bit set; I'm
Joe Conway [EMAIL PROTECTED] writes:
This scenario is probably why Tatsuo wants PQescapeBytea to octalize
everything with the high bit set; I'm not sure there's any lesser way
Yuck! At that point you're no better off than converting to hex (and
worse off than converting to base64) for
(Sorry that my previous post did not reach the pgsql-hackers list, I
sent it from the wrong address and was thus not considered a
subscriber)
Dann Corbit [EMAIL PROTECTED] writes:
But I am a bit puzzled. How can a serializable transaction be
performed in a MVCC system? I realize the Oracle
We had discussed a while ago that it might be a good idea to compile with
debugging symbols by default, at least when using GCC. Personally, I
think that that would be a good idea, for users and developers alike.
If we go with that, I'd like to implement a new target 'install-strip'
that strips
On Fri, 2002-04-05 at 16:55, Peter Eisentraut wrote:
We had discussed a while ago that it might be a good idea to compile with
debugging symbols by default, at least when using GCC. Personally, I
think that that would be a good idea, for users and developers alike.
If we go with that, I'd
-Original Message-
From: Fernando Nasser
Hiroshi Inoue wrote:
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
I don't object to use a search path to resolve unqualified
function, type etc names. But it is very siginificant for
users to be able to be
Tom Lane wrote:
Yuck! At that point you're no better off than converting to hex
(and worse off than converting to base64) for storage.
No; the *storage* is still compact, it's just the I/O representation
that's not.
Yeah, I realized that after I pushed send ;)
But still, doesn't
Joe Conway [EMAIL PROTECTED] writes:
But still, doesn't that mean roughly twice as much memory usage for each
copy of the string? And I seem to remember Jan saying that each datum
winds up having 4 copies in memory. It ends up impacting the practical
length limit for a bytea value.
Well,
Hiroshi Inoue wrote:
We can't do that. Accordingly to the SQL if you are user HIROSHI
and write SELECT * FROM a; the table is actually HIROSHI.a.
This must work for people who are using SQL-schemas in their databases
or we would have a non-conforming implementation of SCHEMAS
Or, as I suggested above, extend the SELECT (and other querys?) syntax
seems reasonable. More so than the non-standard 'use this index, really'
types of extensions that other RDBMSs provide, that we've rightly avoided.
I think we need timeout for all statement.
--
Bruce Momjian
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Could we get out of this by defining that timeout is
automatically reset at next statement end?
I was hoping to avoid that, because it seems like a wart. OTOH,
it'd be less of a wart than the global changes of semantics
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
If at all, SET commands should behave like everything else.
If done inside a transaction, they have to rollback.
I have thought of a scenario that may be sufficient to justify fixing
SETs to roll back on transaction abort.
Fernando Nasser writes:
I does not _have_ to be public, so we can just avoid the issue
by adding a pg_ prefix to public, common or something else.
It is a PostgreSQL concept anyway.
No, it's an Oracle concept.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
In addition, this seems to be the canonical paper on snapshot
isolation:
http://citeseer.nj.nec.com/berenson95critique.html
There is an excellent, more recent paper, Generalized Isolation Level
Definitions (http://citeseer.nj.nec.com/adya00generalized.html).
Af far as I know Oracle doesn't have any short cut (along the lines of
what is being discussed in this thread) for this operation. However
Oracle is more efficient in providing the answer than postgres currently
is. While postgres needs to perform a full scan on the table, Oracle
will only
I was originally planning to revise pg_aggregate along the same lines
as pg_proc and so forth: add an aggnamespace column and fix the search
code to be namespace-aware. But it seemed a tad annoying that standard
function lookups would thereby incur *two* namespace-aware searches:
one in
53 matches
Mail list logo
