Jan Wieck [EMAIL PROTECTED] writes:
vacuum_page_per_delay = 2
vacuum_time_per_delay = 10
That's exactly what I did ... look at the combined experiment posted under
subject Experimental ARC implementation. The two parameters are named
vacuum_page_groupsize and vacuum_page_delay.
FWIW
Tom Lane [EMAIL PROTECTED] writes:
I would like to see us go over to fsync, or some other technique that
gives more certainty about when the write has occurred. There might be
some scope that way to allow stretching out the I/O, too.
The main problem with this is knowing which files need
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
The main problem with this is knowing which files need to be fsync'd.
Why could the postmaster not just fsync *every* file?
You want to find, open, and fsync() every file
Andrew Dunstan [EMAIL PROTECTED] writes:
I think there is room for lots of GUIs, though, and having a Java admin GUI
would be cool too, as would having a servlet/JSP based admin client deployable
as a web archive.
If someone's looking for an interesting GUI project, Applix had a database
Christopher Browne [EMAIL PROTECTED] writes:
Was that a 'native' part of SHELF? Or more related to their TM1
product?
The full source was included in SHELF (if that was the source release I'm
thinking of.) I think it was called axdata.
FYI, while Applix and VistaSource have orphaned it,
Marc G. Fournier [EMAIL PROTECTED] writes:
Actually, the use of schema's was my idea, to speed up some dreadfully
slow queries dealing with traffic stats from a table that was growing
painfully monolithic ... the idea is/was that it would be easier to
backup/remove all data pertaining to a
Bruce Momjian [EMAIL PROTECTED] writes:
Have you considered having the background writer check the pages it is
about to write to see if they can be added to the FSM, thereby reducing
the need for vacuum? Seems we would need to add a statistics parameter
so pg_autovacuum would know how many
Bruce Momjian [EMAIL PROTECTED] writes:
I am not really aiming at removing sync() alltogether. We know already
that open,fsync,close does not guarantee you flush dirty OS-buffers for
which another process might so far only have done open,write. And you
So for what it's worth, though the
. if we used bugzilla this might give some impetus to the bugzilla team's
efforts to provide pg as a backend (maybe we could help with that)
I would actually suggest trying RT. It's not primarily a bug tracking system
and there's a bit of an impedance mismatch between a trouble ticketing
Manfred Spraul [EMAIL PROTECTED] writes:
Greg Stark wrote:
I'm assuming fsync syncs writes issued by other processes on the same file,
which isn't necessarily true though.
It was already pointed out that we can't rely on that assumption.
So the NetBSD and Sun developers I checked
Shridhar Daithankar [EMAIL PROTECTED] writes:
If the parent postmaster mmaps anonymous memory segments and shares them with
children, postgresql wouldn't be dependent upon any kernel resourse aka
shared memory anymore.
Anonymous memory mappings aren't shared, at least not unless you're
Tom Lane [EMAIL PROTECTED] writes:
The other idea I had was to somehow create associations of opclasses,
so that you could say that int2_ops, int4_ops, and int8_ops all sort
values compatibly, so it's okay to go find the operator you need in
int4_ops or int2_ops. I don't have any concrete
+ if (!chmod(pg_data,0700))
Out of curiosity, what was the rationale for using 0700? I know it was a pain
for me when I had a script to monitor the tmp usage. Surely read access to
privileged users isn't really a problem? I'm thinking more of loosening the
paranoia check elsewhere
Neil Conway [EMAIL PROTECTED] writes:
What does BEGIN actually do now, from a user's perspective?
I think you're thinking about this all wrong. BEGIN doesn't do anything.
It's not a procedural statement, it's a declaration. It declares that the
block of statements form a transaction so reads
Mike Mascari [EMAIL PROTECTED] writes:
1) PITR
2) Distributed Tx
3) Replication
4) Nested Tx
5) PL/SQL Exception Handling
Of these PITR seems *by far* the most important. It makes the difference
between an enterprise-class database capable of running 24x7 with disaster
recovery plans, and
Matthew T. O'Connor [EMAIL PROTECTED] writes:
I don't call porting Postgres to run well on something like 40% of the
world's servers (or whatever it is) just another port.
It could conveivably double Postgres's target audience, could attract heaps
of new users, new developers, new
Dann Corbit [EMAIL PROTECTED] writes:
I have all of the above database systems installed on the Windows 2000
machine I am typing this message from. DB/2 7.1
Oracle 8.1.7 and 9.2.0.5
MySQL 4.0.12
Sybase Adaptive Server 12.0
Informix Dynamic Server 9.2
(Also SapDB, Firebird
Alvaro Herrera [EMAIL PROTECTED] writes:
On Tue, Nov 18, 2003 at 02:31:03PM -0800, Sailesh Krishnamurthy wrote:
Another thing I toyed with was having an implementation of a
Tid-List-Fetch .. sorting a TID-list from an index and fetching the
records of the relation off the sorted list for
Tom Lane [EMAIL PROTECTED] writes:
Josh Berkus [EMAIL PROTECTED] writes:
BTW, do we have any provisions to avoid overlapping vacuums? That is, to
prevent a second vacuum on a table if an earlier one is still running?
Yes, VACUUM takes a lock that prevents another VACUUM on the same
Josh Berkus [EMAIL PROTECTED] writes:
I'm a little unclear, personally, about what can be accomplished through table
partitioning that we can't currently do through partial indexes and inherited
tables, especially after Gavin finishes his tablespaces patch (btw, Gavin
could use
Peter Eisentraut [EMAIL PROTECTED] writes:
2. Reimplement gettext to use 1. and allow switching of language and
encoding at run-time.
3. Implement Unicode collation algorithm and character classification
routines that are aware of 1. Use that in place of system locale
routines.
This
Neil Conway [EMAIL PROTECTED] writes:
It occurred to me that these kinds of poor planning decisions could easily
be detected by PostgreSQL itself: after we've finished executing a plan, we
can trivially compare the # of results produced by each node in the query
tree with the # of results
ow [EMAIL PROTECTED] writes:
--- Tom Lane [EMAIL PROTECTED] wrote:
Quite honestly, I think they should check their foreign keys.
What should I do if I *know* there will be a FK failure but I want to correct
it manually. Perhaps by creating all the necessary target records, perhaps by
It seems to me that the root cause of some of the optimizer failures that come
is the optimizer's attempt to assign a single expected cost value to every
choice. In fact it seems it should have also a minimum cost and maximum
cost in addition to the expected cost. Often the optimizer is faced
Neil Conway [EMAIL PROTECTED] writes:
I was thinking about this, but I couldn't think of how to get it to
work properly:
(1) The optimizer's cost metric is somewhat bogus to begin with.
ISTM that translating a cost of X into an expected runtime of
Y msecs is
Gaetano Mendola [EMAIL PROTECTED] writes:
The count(*) information can be revisioned too, am I wrong ? I'm able to
create a trigger that store the count(*) information in a special table,
why not implement the same in a way builded in ?
Then every insert or delete would have to lock that
Lamar Owen [EMAIL PROTECTED] writes:
So, no, -fPIC does not appear to be required for libpq.
My understanding was that at least on some platforms once you need -fPIC for
some libraries you need to make sure they were all compiled with it. That
means it's a pain if any libraries are provided
Joe Conway [EMAIL PROTECTED] writes:
How is a parameterized view any different than a set returning SQL function?
In either case, you've got the same work to do to teach the optimizer how to
understand it, no? Seems like the todo is just that, teach the optimizer how to
do better with
Jonathan Gardner [EMAIL PROTECTED] writes:
Usually, it is data that is related to each other somehow. I guess an
example would be for an internet host who wants to provide a common
shopping cart functionality for all of its customers, but put their
specific data on a specific partition for
Oliver Elphick [EMAIL PROTECTED] writes:
Then it needs to be stated very prominently. But the place to put a
sign saying Dangerous cliff edge is beside the path that leads along
it.
The only way to make this prominent would be a file with the *name* THIS
DIRECTORY CONTAINS CRITICAL DATA.
Stephan Szabo [EMAIL PROTECTED] writes:
I'd expect copy to be a single command, no matter how many rows were
copied.
It might prevent you from using pg_dump --inserts ?
--
greg
---(end of broadcast)---
TIP 5: Have you checked our extensive
Hannu Krosing [EMAIL PROTECTED] writes:
Greg Stark kirjutas E, 01.12.2003 kell 18:15:
Separate OS partitions is a reasonable use of partitioned tables, but the
biggest advantage is being able to drop and load partitions very quickly, and
without impacting performance at all. loading
Bruce Momjian [EMAIL PROTECTED] writes:
I hate to reply to this because I have already cast my vote, but
block_size does not report the size of a disk block. It reports the
size of a PostgreSQL block/page. Disk blocks are almost always 512
bytes in size.
Perhaps then neither block nor page
I have an idea for what I think may be a very simple optimization for postgres
to make. I would like to try my hand at implementing it, but the last time I
tried I apparently started off in the wrong direction.
In the following query, the sort step is completely unnecessary. The order is
I know Oracle is capable of producing the UNION plan. but I don't know if
that's the only option. I'm curious what indexes the rewritten union-based
query used.
Josh Berkus [EMAIL PROTECTED] writes:
SELECT t1.a, t2.b
FROM t1, t2
WHERE t1.a = t2.a
AND (
( t1.c = x
AND t1.f IN
Dann Corbit [EMAIL PROTECTED] writes:
From the C-FAQ:
A:Not portably, it doesn't. It attempts to modify the variable a
twice between sequence points, so its behavior is undefined.
10.3: How can I write a generic macro to swap two values?
Neither of these are really relevant,
int CRYPTO_set_locked_mem_functions(void *(*m)(size_t), void (*free_func)(void
*));
If there's a missing typedef shouldn't we see something like this:
`size_t' undeclared (first use in this function)
(assuming he is using gcc)?
Try it.
typedefs are weird in the C language,
Hannu Krosing [EMAIL PROTECTED] writes:
SELECT x.*
FROM x,
(select match (x.foo, '([0-9]+)x([0-9]+)')
from x innerx
where innerx.pk = x.pk
) as res
HAVING y = get_match_group(res, 2)
OR y = get_match_group(res, 3)
;
Well you don't need to go fetch from
Neil Conway [EMAIL PROTECTED] writes:
We reject the following query:
nconway=# create table abc (a int, b int, c int);
CREATE TABLE
nconway=# select distinct on (a) a, b, c from abc order by b, c, a;
ERROR: SELECT DISTINCT ON expressions must match initial ORDER BY
expressions
What
Kurt Roeckx [EMAIL PROTECTED] writes:
I'm trying to change all the walkers and mutators to have a more
strict prototype. I had to do this with lots of casts.
I don't really like the idea of having all those generic pointer
types (Node * and void *), but currently see no better way to deal
Kurt Roeckx [EMAIL PROTECTED] writes:
I did start by changing all the context's to void *, but you'll
loose the real type that it gets called with, so the other calls
will not generate warnings anymore because of wrong type.
But at least you'll get a warning if someone passes a non-pointer
Andrew Dunstan [EMAIL PROTECTED] writes:
Second, you state that this usage is valid. When you first raised the
matter, you were so certain that it was sanctified by standard that you
asked me if I would implement it if you could quote an RFC sanctifying it
(I said yes) and went off to find
Kurt Roeckx [EMAIL PROTECTED] writes:
It's a.b.0.c.
Note that the c can be bigger than 255, so 128.1.512 turns into
128.1.2.0. This can make perfect sense when you still used
classes.
Perhaps it'll seem less strange if I restate the rule so there aren't four
different cases:
A dotted
Dennis Björklund [EMAIL PROTECTED] writes:
I would rather have long commands so one can write
\describe_table foo
I would think it would be better to keep everything under a single command and
have a 1-1 correspondence to \d. Ie, just add a long form syntax following the
existing \d. \d
Bruce Momjian [EMAIL PROTECTED] writes:
Hannu Krosing wrote:
Eric Ridge kirjutas R, 09.01.2004 kell 01:16:
Forgetting about composite indexes for a moment, is postgres even
capable of doing 2 index scans in this situation? Does it know how do
take the intersection of two scans?
Tom Lane [EMAIL PROTECTED] writes:
Brian Moore [EMAIL PROTECTED] writes:
i would like to begin work on the TODO item
Allow backend to output result sets in XML
I am not sure why it's phrased that way --- surely the code to hack on
is the client side, not the backend. Otherwise you
Tom Lane [EMAIL PROTECTED] writes:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
FreeBSD 4.7/4.9 and the UFS filesystem
Hm, okay, I'm pretty sure that that combination wouldn't report ENOSPC
at close(). We need to fix the code to check close's return value,
probably, but it seems we
[EMAIL PROTECTED] (David Fetter) writes:
In article [EMAIL PROTECTED] you wrote:
I've been looking (and coded) a little bit on named function calls.
Calls on the form:
foo (x = 13, y = 42)
Implementing this means that the symbol = no longer can be defined
by the user as an
Dennis Bjorklund [EMAIL PROTECTED] writes:
On 25 Jan 2004, Greg Stark wrote:
foo (x = 13, y = 42)
Is it really necessary to steal it?
Yes, it is necessary since the arguments to a function are just
expressions. If you do not the above would be ambigious
How feasible would it be to have a btree index on ctid? I'm thinking it ought
to work simply enough for the normal case of insert/delet/update, but I'm not
completely certain how vacuum, vacuum full, and cluster would interact.
You may think this would be utterly useless, but I have a cunning
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
How feasible would it be to have a btree index on ctid?
Why would you want one? Direct access by ctid beats out an index lookup
every time.
Of course. But as I mentioned, I have a cunning plan.
If you have two
Tom Lane [EMAIL PROTECTED] writes:
I don't think so. You are thinking only of exact-equality queries ---
as soon as the WHERE clause describes a range of index entries, the
readout wouldn't be sorted by ctid anyway.
But then even bitmap indexes would fail in that way too, or at least have a
Tom Lane [EMAIL PROTECTED] writes:
In any case, this discussion is predicated on the assumption that the
operations involving the bitmap are a significant fraction of the total
time, which I think is quite uncertain. Until we build it and profile
it, we won't know that.
The other thought I
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
I would see that as the next step, But it seems to me it would be only a small
set of queries where it would really help enough to outweigh the extra work of
the sort.
What sort?
To build the in-memory bitmap
Simon Riggs [EMAIL PROTECTED] writes:
In the past, I have used the dd command to squirt data at the disk, then
read it back again - but there may be reasons I don't know why a success on
that test might not be conclusive, so I personally would be happy to defer
to someone that does.
Well
Tom Lane [EMAIL PROTECTED] writes:
Marc G. Fournier [EMAIL PROTECTED] writes:
What happens if I abort on the first transaction? If I'm reading this
right, if Trans2 does the exact same as above, and COMMITs before Trans1
Aborts, the value of balance becomes +200 (Trans2 + Trans1) ... but
Tom Lane [EMAIL PROTECTED] writes:
That seems a bit too lossy for me, but I really like your later idea
about folding. Generalizing that a little, we can choose any fold point
we like. We could allocate, say, one 32-bit word per page and set the
(i mod 32) bit when item i is fingered by
Manfred Spraul [EMAIL PROTECTED] writes:
That means
open();
write();
sync();
could succeed, but the data is not stored on disk, correct?
That would be true on any filesystem. Unless you throw an fsync() call in.
With sync replaced by fsync then any filesystem ought to
Manfred Spraul [EMAIL PROTECTED] writes:
The checkpoint code uses sync() right now. Actually sync();sleep(2);sync().
Win32 has no sync() call, therefore it will use fsyncs. Perhaps platforms with
deferred errors on close must use fsync, too. Hopefully parallel fsyncs -
sequential fsyncs
Bruce Momjian [EMAIL PROTECTED] writes:
As some know, win32 doesn't have sync, and some are concerned that sync
isn't reliable enough during checkpoint anyway.
The trick is to somehow record all files modified since the last
checkpoint, and open/fsync/close each one.
Note that some people
Tom Lane [EMAIL PROTECTED] writes:
Orion Henry [EMAIL PROTECTED] writes:
It appears to be faulting on a kerberos call which is odd because I
don't use kerberos for anything.
I was a bit surprised to realize that if you compile Kerberos support at
all, libpq will try to get a user name
Bruce Momjian [EMAIL PROTECTED] writes:
Edwin S. Ramirez wrote:
Hello,
Is is possible to change the transaction behaviour not to abort when a
syntax error occurs.
I've done some searches on the list, and have not found anything.
No, we need nested transactions for that. We are
Tom Lane [EMAIL PROTECTED] writes:
What it comes down to is that a lot of code in the backend assumes that
transaction abort can be relied on to do any post-elog cleanup needed,
such as releasing locks or reclaiming leaked memory. I don't think we
can afford to give up that assumption; the
Tom Lane [EMAIL PROTECTED] writes:
It seems to me that that's too narrow a definition of the problem.
I think we should state our goal as we don't want bizarre locale
definitions to interfere with downcasing of the basic ASCII letters.
If we put in a special case for 'I' we will fix the
Jan Wieck [EMAIL PROTECTED] writes:
The whole sync() vs. fsync() discussion is in my opinion nonsense at this
point. Without the ability to limit the amount of files to a reasonable number,
by employing tablespaces in the form of larger container files, the risk of
forcing excessive head
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
If it matches an SQL keyword after being downcased the old fashioned way, then
it's an SQL keyword. If not then the locale-aware tolower() would be
appropriate for tables, columns, etc.
That's exactly what we do
Tom Lane [EMAIL PROTECTED] writes:
Hmmm ... maybe query_work_mem and maintenance_work_mem, or something
similar?
I'll go with these unless someone has another proposal ...
dml_sort_mem and ddl_sort_mem ?
--
greg
---(end of broadcast)---
I am expecting to hear some bleating about this from people whose
preferred platforms don't support symlinks ;-). However, if we don't
Well, one option would be to have the low level filesystem storage (md.c?)
routines implement a kind of symlink themselves. Just a file with a special
magic
Tom Lane [EMAIL PROTECTED] writes:
I would favor using Bugzilla over anything else just because I'm used
to it (have to use it internally at Red Hat anyway).
I might suggest again RT. It's open source and has serious commercial
traction. The postgres port needs a lot of work for it to really
Tom Lane [EMAIL PROTECTED] writes:
This function breaks the whole backend if an elog() failure occurs while
it's got the wrong locale set. I believe it would also be remarkably
slow --- doesn't setlocale() involve reading a new locale definition
file from whereever those are stored?
I
Tom Lane [EMAIL PROTECTED] writes:
As for raising the barrier, you can presently submit bug reports to
pgsql-bugs by either mail or webform. Most of the bug trackers I'm
aware of are webform-only. I don't consider that a step forward,
especially since a webform isn't very conducive to
Joe Conway [EMAIL PROTECTED] writes:
I wrestled with the same issue last year.
Offhand I don't know how hard it would be to do, but I wonder if when we see:
argL IN (argR)
we might be able to determine if argL and argR are of the same type or if argR
is an array of argL, and act
Uhm. oops. I'll just crawl back under this rock for a bit longer before I
speak on this topic again. sorry.
--
greg
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Bruce Momjian [EMAIL PROTECTED] writes:
Greg Stark wrote:
I am expecting to hear some bleating about this from people whose
preferred platforms don't support symlinks ;-). However, if we don't
Well, one option would be to have the low level filesystem storage (md.c?)
routines
Jan Wieck [EMAIL PROTECTED] writes:
the point is that PostgreSQL is no GNU product, never has been and if someone
intends to he shall do so after yanking out the contributions I made.
Note that when you released your contributions you did so under a license that
imposed no such conditions. If
Simon Riggs [EMAIL PROTECTED] writes:
Strict behaviour is fairly straightforward, you just PANIC!
There is another mode possible as well. Oracle for example neither panics nor
continues, it just freezes. It keeps retrying the transaction until it finds
it has space.
The sysadmin or dba just
Bruce Momjian [EMAIL PROTECTED] writes:
The issue is allowing only logging of DDL statements, or DDL and data
modification statements, as listed on the TODO list. If they ask for
all statements, certainly we should log all statements.
just make syntax errors one of the types. So you could
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
Consider either a box with many different postgresql instances, or one
that run both postgresql and other software. Issuing sync() in that
sitaution will cause sync of a lot of data that probably doesn't need
syncing.
But it'd
Tom Lane [EMAIL PROTECTED] writes:
This seems, um, hard to believe. Did he shut down the standard syncer
daemon? I have never seen a Unix system that would allow more than
thirty seconds' worth of unwritten buffers to accumulate, and would not
care to use one if it existed.
Well it was
David Garamond [EMAIL PROTECTED] writes:
Also, we're targetting the developers right? Please do not consider
ourselves as being too stupid to differentiate between postgresql.org and
postgresql.net...
I can never remember whether the current site is postgresql.{com,org,net} even
now. Making
Sailesh Krishnamurthy [EMAIL PROTECTED] writes:
Tom == Tom Lane [EMAIL PROTECTED] writes:
Tom I'm not sure that this would let us catch up to what Arjen
Tom reports as MySQL's expression evaluation speed, but it should
Tom at least speed things up a bit with only fairly
Tom Lane [EMAIL PROTECTED] writes:
b) Instead of storing one of a small set of function pointers in every
node of every expression, wouldn't it make more sense to have a table
lookup from node type to function pointer?
That's pretty much what the ExecEvalExpr switch() does already, on
Tom Lane [EMAIL PROTECTED] writes:
BTW, something that just occurred to me now: EXPLAIN is currently really
designed only for SELECTs. It would make sense to upgrade it for
INSERT/UPDATE/DELETE to list the triggers that will get fired. While
we'd have to treat user triggers as black boxes,
Tom Lane [EMAIL PROTECTED] writes:
I could go with that too. The question here is do we have any popular
use-cases that aren't solved by that extension, but could be solved by
simple user-level data formatting functions? I'm not real eager to add
such a feature as an if we build it they
Tom Lane [EMAIL PROTECTED] writes:
We have a number of issues revolving around the fact that composite types
(row types) aren't first-class objects. I think it's past time to fix
that.
...
Only named composite types, not RECORD, will be allowed to be used as
table column types.
If I
Josh Berkus [EMAIL PROTECTED] writes:
Joe,
This is correct. There are no dimensions to an empty array by
definition. The only other way to handle this would be an ERROR. I
followed the lead of (the pre-existing function) array_dims() when
creating array_upper() and array_lower().
J. Andrew Rogers [EMAIL PROTECTED] writes:
I may be completely missing the point here, but it looks to me as though
the PITR archival mechanism is also most of a native replication
facility. Is there anyone reason this couldn't be extended to
replication, and if so, is anyone planning on
Joe Conway [EMAIL PROTECTED] writes:
Same here; this would be:
array_upper(a || b) == array_upper(a) + CARDINALITY(b)
and would work just fine. Note that if array-a is NULL, then the spec defines a
|| b as NULL. See section 6.35:
Why are you talking about when a is NULL? The original
Joe Conway [EMAIL PROTECTED] writes:
You seem to be saying that because the output of certain functions that operate
on empty arrays is NULL, it somehow implies that the array is being treated as
NULL -- that's just plain incorrect.
Not incorrect, but a sign something weird is going on. It
Tom Lane [EMAIL PROTECTED] writes:
Hm. My idea of the index lower bound is the smallest index for which
there is an array member --- so I agree with Joe that it's not very
well defined for an empty array.
Hm. The problem is that they have other implications. Like the upper bound is
one
Tom Lane [EMAIL PROTECTED] writes:
That would break even more things, no?
On the other hand, it'd get rid of the problem that we presently face
with dump/restore of arrays that don't have lower bound 1. Because
pg_dump doesn't do anything to mark such values, they'll end up with
lower
Joe Conway [EMAIL PROTECTED] writes:
Greg Stark wrote:
I'm leaning towards suggesting that postgres should follow sql-99 here and
normalize all array indexes to have a lower bound of 1. Then array_lower and
array_upper become entirely unnecessary. Instead we just have array_length
which
Joe Conway [EMAIL PROTECTED] writes:
Greg Stark wrote:
array_lower() and array_upper() are returning NULL for a non-null input, the
empty array, even though lower and upper bounds are known just as well as they
are for any other sized array. They are behaving as if there's something
Joe Conway [EMAIL PROTECTED] writes:
Greg Stark wrote:
This really ought to work, it obviously shouldn't allow you to set a[5] and
then surreptitiously move it to a[1]. But nor should it generate an error,
since I may well have a specific meaning for a[5] and may be planning to fill
Joe Conway [EMAIL PROTECTED] writes:
I'd think given the preceding, it would make more sense to throw an error
whenever trying to access an element greater than the length.
For an analogous situation in SQL I would propose
select (select foo from bar where xyz);
if there are no records in
Stephen Frost [EMAIL PROTECTED] writes:
c)
merge into T1 USING VALUES (1,2,4);
I'm not happy with the implied use of the primary key. a) some tables can have
two effective primary keys, even if only one is explicitly declared as such.
and b) some update/inserts are done with where clauses
Shachar Shemesh [EMAIL PROTECTED] writes:
Also, if we want greater flexibility in handling these cases in the future, we
should set up an invite-only list for reporting security bugs, and advertise it
on the web site as the place to report security issues. Had this vulnerability
been
scott.marlowe [EMAIL PROTECTED] writes:
but I'm not sure you can test that without power off tests...
Well the approach that's been taken manually on the list is to look at the
timing results and conclude they're just physically impossible.
Doing this automatically could be interesting. If
think the hash function can
be improved without breaking it.
On Tue, May 04, 2004 at 06:45:37PM -0400, Greg Stark wrote:
Regarding inter-data-type hash joins, would it make sense to make float
datatypes to hash to the same value as integral data types for integral
values?
I have a little
Fabien COELHO [EMAIL PROTECTED] writes:
I agree with the advantage.
But I'm uneasy to know what a special owner would be, pratically speaking.
If it would mean that everywhere in the source code where an owner is
manipulated, there must be some kind of special test for that case, I'm
not
1 - 100 of 2904 matches
Mail list logo
