On Sun, 22 Nov 2009, Emmanuel Cecchet wrote:
As I explained to Tom, if the after row trigger is called asynchronously
I get a relcache leak on the child table at the end of the copy
operation. If the trigger is called synchronously (like a before row
trigger) it works fine. Also calling the
On Sun, 22 Nov 2009, Emmanuel Cecchet wrote:
Stephan Szabo wrote:
On Sun, 22 Nov 2009, Emmanuel Cecchet wrote:
As I explained to Tom, if the after row trigger is called asynchronously
I get a relcache leak on the child table at the end of the copy
operation. If the trigger is called
On Fri, 16 Oct 2009, Tom Lane wrote:
I note BTW that we have some ad-hoc logic already that arranges to
suppress queuing of AFTER events for FK triggers, if the FK column
value has not changed. It might be interesting to look at whether
that hack could be unified with the user-accessible
On Sun, 1 Mar 2009, Tom Lane wrote:
I wrote:
The standard doesn't have multi-dimensional arrays, so it's entirely
possible that somewhere in it there is wording that makes cardinality()
equivalent to the length of the first dimension. But I concur with
Andrew that this is flat wrong
On Tue, 23 Dec 2008, Kevin Grittner wrote:
The page locking provides this because every index page or data page
the serializable transaction looks at is locked against updates until
the end of the transaction. If it can see all the COLUMN=0 rows
through an index, the index locks protect the
On Mon, 18 Feb 2008, Tom Lane wrote:
Alexey Nalbat [EMAIL PROTECTED] writes:
create table t1 ( id integer primary key, name text );
create table t2 ( id integer references t1 );
insert into t1 values ( 1 );
insert into t2 values ( 1 );
Then two concurrent transactions start.
/* 1
On Fri, 5 Oct 2007, Simon Riggs wrote:
On Fri, 2007-10-05 at 11:24 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs wrote:
On Fri, 2007-10-05 at 10:59 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs wrote:
On Fri, 2007-10-05 at 10:32 -0700, Stephan
On Sat, 6 Oct 2007, Simon Riggs wrote:
On Sat, 2007-10-06 at 10:15 -0700, Stephan Szabo wrote:
Yeh, it does, but you're forgetting that my original complaint was that
you couldn't use it in an ANY clause, which 4.2 does not exclude.
Bearing in mind you can use a scalar subquery
On Fri, 5 Oct 2007, Simon Riggs wrote:
Because we already do exactly that here:
select 1, (select col2 from c), 3;
The inner select returns a ROW, yet we treat it as a single column
value.
The inner select does not return a row. It's not a row subquery, it's a
scalar subquery.
On Fri, 5 Oct 2007, Simon Riggs wrote:
On Fri, 2007-10-05 at 10:32 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs wrote:
Because we already do exactly that here:
select 1, (select col2 from c), 3;
The inner select returns a ROW, yet we treat it as a single
On Fri, 5 Oct 2007, Simon Riggs wrote:
On Fri, 2007-10-05 at 10:59 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs wrote:
On Fri, 2007-10-05 at 10:32 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs wrote:
Because we already do exactly that here
On Fri, 10 Aug 2007, Tom Lane wrote:
I noticed the following behavior in CVS HEAD, using a pattern that is
capable of matching no characters:
regression=# SELECT foo FROM regexp_matches('ab cde', $re$\s*$re$, 'g') AS
foo;
foo
---
{}
{}
{ }
{}
{}
{}
{}
(7 rows)
On Tue, 17 Apr 2007, Tom Lane wrote:
A recent discussion led me to the idea that FK triggers are fired
unnecessarily during an UPDATE if the foreign-key column(s) contain
any NULLs, because ri_KeysEqual() treats two nulls as unequal,
and therefore we conclude the row has changed when it has
On Tue, 17 Apr 2007, Tom Lane wrote:
A recent discussion led me to the idea that FK triggers are fired
unnecessarily during an UPDATE if the foreign-key column(s) contain
any NULLs, because ri_KeysEqual() treats two nulls as unequal,
and therefore we conclude the row has changed when it has
On Wed, 11 Apr 2007, Jim Nasby wrote:
I agree with others that the way that query is constructed is a bit
odd, but it does bring another optimization to mind: when doing an
inner-join between a parent and child table when RI is defined
between them, if the query only refers to the child table
On Wed, 21 Feb 2007, Martijn van Oosterhout wrote:
On Wed, Feb 21, 2007 at 12:06:30PM -0500, Phil Currier wrote:
Well, for two reasons:
1) If you have a table with one very-frequently-accessed varchar()
column and several not-frequently-accessed int columns, it might
actually make
On Wed, 21 Feb 2007, Alvaro Herrera wrote:
Stephan Szabo escribi?:
On Wed, 21 Feb 2007, Martijn van Oosterhout wrote:
On Wed, Feb 21, 2007 at 12:06:30PM -0500, Phil Currier wrote:
Well, for two reasons:
1) If you have a table with one very-frequently-accessed varchar
On Mon, 12 Feb 2007, Tom Lane wrote:
I wrote:
* Add an oid[] column to pg_constraint that stores the equality operator
OIDs for a foreign-key constraint, in the same column order as conkey[]
and confkey[].
It turns out this isn't sufficient: ri_Check_Pk_Match() wants to
generate PK = PK
On Fri, 9 Feb 2007, Tom Lane wrote:
Almost a year ago, we talked about the problem that referential
integrity should be selecting comparison operators on the basis
of b-tree index opclasses, instead of assuming that the appropriate
operator is always named =:
On Sat, 10 Feb 2007, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
One side question is what should we do about the
places in the current system where it checks for the key sets being empty?
I don't see that this affects that either way. I can't quite imagine
what the semantics
On Thu, 8 Feb 2007, Marc Munro wrote:
Oops, forgot to include pgsql-hackers when I responded to this the first
time.
On Tue, 2007-06-02 at 20:53 -0500, Tom Lane wrote:
Marc Munro [EMAIL PROTECTED] writes:
The RI triggers currently fire when a record is updated. Under my
proposal
On Thu, 8 Feb 2007, Marc Munro wrote:
On Thu, 2007-08-02 at 10:06 -0800, Stephan Szabo wrote:
On Thu, 8 Feb 2007, Marc Munro wrote:
. . .
That other transaction, T1, would have run the same RI triggers and so
would have the same parent records locked.
That's not true in the case
On Mon, 5 Feb 2007, Simon Riggs wrote:
On Sun, 2007-02-04 at 09:38 +, Simon Riggs wrote:
The TODO I was requesting you consider was this:
Develop non-conflicting locking scheme to allow RI checks to co-exist
peacefully with non-PK UPDATEs on the referenced table.
That
On Sat, 3 Feb 2007, Simon Riggs wrote:
On Fri, 2007-02-02 at 16:50 -0500, Tom Lane wrote:
No, I don't. I think knowledge of which columns are in a PK is quite a
few levels away from the semantics of row locking. To point out just
one problem, what happens when you add or drop a PK? Or
On Fri, 2 Feb 2007, Simon Riggs wrote:
It sounds like if we don't put a SHARE lock on the referenced table then
we can end the transaction in an inconsistent state if the referenced
table has concurrent UPDATEs or DELETEs. BUT those operations do impose
locking rules back onto the referencing
On Tue, 31 Oct 2006, Chuck McDevitt wrote:
We treated quoted identifiers as case-specific, as the spec requires.
In the catalog, we stored TWO columns... The column name with case
converted as appropriate (as PostgreSQL already does), used for looking
up the attribute,
And a second column,
On Sun, 10 Sep 2006, Gregory Stark wrote:
Chris Mair [EMAIL PROTECTED] writes:
What's the purpose of letting you insert 1000 records, then, at the end
say: hah, all is rolled back becauase the 2nd record was invalid.
PG justly throws the exception immediately to let you know it's futile
On Sun, 10 Sep 2006, Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Stephan Szabo [EMAIL PROTECTED] writes:
I think if we were going to do this that all the constraint violations for
unique, not null, check and foreign keys should be handled similarly, so
we'd probably want
On Sat, 9 Sep 2006, Jan de Visser wrote:
On Saturday 09 September 2006 01:33, [EMAIL PROTECTED] wrote:
I don't think so. If it isn't 128 bits - and you want to fit it into
128 bits, it means padding. Where should the padding go? As application
specific, it is up to the application to
Now that I've got a little time again...
Per the report from Clark C Evans a while back and associated discussion,
it seems like recent versions of the SQL spec changed the rules for
foreign key column references such that the columns of the referenced
unique constraint must be named in order
On Wed, 17 May 2006, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Per the report from Clark C Evans a while back and associated discussion,
it seems like recent versions of the SQL spec changed the rules for
foreign key column references such that the columns of the referenced
ergh, hit send before finishing
On Wed, 17 May 2006, Stephan Szabo wrote:
On Wed, 17 May 2006, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Per the report from Clark C Evans a while back and associated discussion,
it seems like recent versions of the SQL spec changed
On Wed, 17 May 2006, Tom Lane wrote:
I'm more inclined to think that we've messed up the information_schema
somehow ...
As usual, you're right. ;)
Actually, it wasn't precisely that we messed it up as much as the 99
defintion was wrong. It's pointed out in the 2003 schemata
incompatibilities
On Wed, 15 Mar 2006, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
The main options seem to be:
When we're allowing other order access, immediately reorder the
constraint information to match the primary key order. This helps out
with IS since the loaded constraint should
[Resurrecting an old thread]
On Sat, 25 Feb 2006, Clark C. Evans wrote:
On Sat, Feb 25, 2006 at 12:51:51PM -0800, Stephan Szabo wrote:
| * for foreign-key and check constraints, the default names
| are $1, $2, etc.; it would be great if they were upgraded
| to use the default
On Wed, 15 Mar 2006, Clark C. Evans wrote:
On Tue, Mar 14, 2006 at 08:14:12PM -0800, Stephan Szabo wrote:
| CREATE TABLE x (y text, z text, PRIMARY KEY(y,z));
| CREATE TABLE a (b text, c text);
| ALTER TABLE a ADD FOREIGN KEY (b, c) REFERENCES x(z, y);
...
| I assert
On Tue, 14 Mar 2006, Stephan Szabo wrote:
We need to offer this for spec complience reasons, but I don't think it
actually fixes the problem you would have with information_schema.
Which of course is wrong, as i figured out when the discussion came up the
first time and forgot when I came
On Wed, 15 Mar 2006, Clark C. Evans wrote:
On Tue, Mar 14, 2006 at 10:01:16PM -0800, Stephan Szabo wrote:
| The point is that because rows in a table don't have order (unless
| information_schema has special rules) the two constraints above seem to
| look the same to me
On Wed, 15 Mar 2006, Clark C. Evans wrote:
On Tue, Mar 14, 2006 at 11:11:29PM -0800, Stephan Szabo wrote:
| When we're allowing other order access, immediately reorder the
| constraint information to match the primary key order.
Let me try to parrot. In PostgreSQL, the pairing information
On Thu, 9 Mar 2006, Josh Berkus wrote:
Jonah,
This email is a preliminary design for the implementation of synonyms in
PostgreSQL. Comments and suggestions are welcomed.
1) Is there a SQL standard for this?
2) For my comprehension, what's the difference between a SYNONYM and a
On Thu, 9 Mar 2006, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
On Thu, 9 Mar 2006, Josh Berkus wrote:
2) For my comprehension, what's the difference between a SYNONYM and a
single-object (possibly updatable) view?
I think with the plan as described, the permissions handling
On Wed, 8 Mar 2006, Hannu Krosing wrote:
??hel kenal p??eval, E, 2006-03-06 kell 17:25, kirjutas Bruce Momjian:
Hannu Krosing wrote:
?hel kenal p?eval, E, 2006-03-06 kell 12:12, kirjutas Bruce Momjian:
Added to TODO:
o Prevent parent tables from altering or dropping
On Fri, 3 Mar 2006, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
On Thu, 2 Mar 2006, Tom Lane wrote:
1. If the index opclass contains an exact operator for the case
PKtype = FKtype, use that operator.
Is this rule to read explicitly naming '=' or just the item
On Fri, 3 Mar 2006, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
There's a bit of difference between not encouraging it and disallowing it
entirely, but I'm willing to buy that argument. I do think that numeric
reference int needs to be allowed though, and I thought that's
On Fri, 3 Mar 2006, Tom Lane wrote:
The reason I'm hesitant to add a bunch more cross-type operators is
mainly that we have too darn many operators named = already. I've
seen in recent profiling tests that it's taking the parser a noticeable
amount of time to decide which one is meant. So I
On Fri, 3 Mar 2006, Tom Lane wrote:
BTW, I had another thought about this: if we go this way, then the plans
associated with RI check queries would essentially always be trivial
index lookups (for everything except RI_Initial_Check). It'd be within
the realm of feasibility to throw away the
On Thu, 2 Mar 2006, Tom Lane wrote:
[ returning to a week-old thread... ]
Stephan Szabo [EMAIL PROTECTED] writes:
On Thu, 23 Feb 2006, Tom Lane wrote:
Any thoughts about details? My feeling is that we should tie RI
semantics to btree opclasses, same as we have done for ORDER
On Wed, 1 Mar 2006, Hannu Krosing wrote:
Ühel kenal päeval, K, 2006-03-01 kell 15:18, kirjutas Bruce Momjian:
Stephan Szabo wrote:
justify_days doesn't currently do anything with this result --- it
thinks its charter is only to reduce day components that are = 30 days.
However, I
On Sat, 25 Feb 2006, Clark C. Evans wrote:
On Sat, Feb 25, 2006 at 11:51:55AM -0800, Josh Berkus wrote:
| This has been discussed previously in a couple of threads. I believe the
| desire is to make it work as specified in SQL-2003, but I do not remember
| whether or not anyone
On Sat, 25 Feb 2006, Stephan Szabo wrote:
On Sat, 25 Feb 2006, Clark C. Evans wrote:
On Sat, Feb 25, 2006 at 11:51:55AM -0800, Josh Berkus wrote:
| This has been discussed previously in a couple of threads. I believe the
| desire is to make it work as specified in SQL-2003, but I do
On Sat, 25 Feb 2006, Clark C. Evans wrote:
On Sat, Feb 25, 2006 at 12:51:51PM -0800, Stephan Szabo wrote:
| * for foreign-key and check constraints, the default names
| are $1, $2, etc.; it would be great if they were upgraded
| to use the default names given by primary
On Sat, 25 Feb 2006, Stephan Szabo wrote:
On Sat, 25 Feb 2006, Clark C. Evans wrote:
On Sat, Feb 25, 2006 at 12:51:51PM -0800, Stephan Szabo wrote:
| * for foreign-key and check constraints, the default names
| are $1, $2, etc.; it would be great if they were upgraded
On Sun, 26 Feb 2006, Clark C. Evans wrote:
Stephen,
So, a quick re-cap of the questions/concerns I had:
* Making the default constraint names include the table
- This was implemented in 8.x, thank you!
* Forbidding the creation of a foreign key constraint where
the column
On Sun, 26 Feb 2006, Clark C. Evans wrote:
On Sat, Feb 25, 2006 at 04:50:41PM -0500, Rod Taylor wrote:
On Sat, Feb 25, 2006 at 02:01:00PM -0800, Stephan Szabo wrote:
| On Sat, 25 Feb 2006, Clark C. Evans wrote:
|
| CREATE TABLE x (y text, z text, PRIMARY KEY(y,z));
| CREATE
On Thu, 23 Feb 2006, Pavel Stehule wrote:
Right, but does the pattern_ops one have to be unique?
Sorry, I don't uderstand
Are you trying to guarantee uniqueness on the pattern_ops rules. My
understanding is that pattern_ops is not just a special index that allows
like comparisons using the
On Thu, 23 Feb 2006, Tom Lane wrote:
I looked into the problem reported here:
http://archives.postgresql.org/pgsql-admin/2006-02/msg00261.php
To wit, a pg_restore of a foreign key constraint involving user-defined
types produces
pg_restore: WARNING: foreign key constraint luuid_fkey will
On Wed, 22 Feb 2006, Mark Woodward wrote:
Mark Woodward wrote:
I'm not sure that I agree. At least in my experience, I wouldn't have
more
than one installation of PostgreSQL in a production machine. It is
potentially problematic.
I agree with you for production environments,
On Wed, 22 Feb 2006, Pavel Stehule wrote:
Why would you need it?
I can't to use unique index for like_op without setting opclass, because I
have to use czech locale. I can create second index, but then I have two
equal indexes. Example:
number | description
000102 blabla bla
000103
On Wed, 22 Feb 2006, Pavel Stehule wrote:
I seem to recall someone proposing extending the syntax of the UNIQUE
constraints themselves, but there really isn't enough use-case to
justify it AFAICS. Especially not when you can always use CREATE
UNIQUE
INDEX.
I can always use
On Tue, 21 Feb 2006, Mark Woodward wrote:
Mark Woodward wrote:
The pg_config program needs to display more information, specifically
where the location of pg_service.conf would reside.
pg_config --sysconfdir
Hmm, that doesn't show up with pg_config --help.
[EMAIL PROTECTED]:~$
On Sat, 18 Feb 2006, Tom Lane wrote:
Milen A. Radev [EMAIL PROTECTED] writes:
Milorad Poluga :
SELECT '10 years 1 mons 1 days'::interval - '9 years 10 mons 15
days'::interval
?column?
---
3 mons -14 days
Why not '2 mons 16 days' ?
Please read the last
On Fri, 10 Feb 2006 ohp@pyrenet.fr wrote:
After a typo, I've just noticed the following :
~ 14:58:33: createdb test
CREATE DATABASE
~ 14:58:42: psql test
Welcome to psql 8.1.2, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL
On Fri, 10 Feb 2006 ohp@pyrenet.fr wrote:
My understanding is that null or not, their should have been a foreign key
violation.
Not as far as I can tell. MATCH (without partial or full) returns true if
any column in the row value constructor is NULL. MATCH FULL returns true
if all columns in
On Mon, 6 Feb 2006, Josh Berkus wrote:
Are you sure that a new type of constraint is the way to go for this?
It doesn't solve our issues in the data warehousing space. The spec we
started with for Error-tolerant COPY is:
1) It must be able to handle parsing errors (i.e. bad char set);
2)
On Mon, 6 Feb 2006, James William Pye wrote:
On Sun, Feb 05, 2006 at 07:14:49PM -0800, Stephan Szabo wrote:
On Sun, 5 Feb 2006, James William Pye wrote:
However, constraints referenced in an UNLESS clause that are deferred, in
any
fashion, should probably be immediated within
On Fri, 3 Feb 2006, James William Pye wrote:
Despite the fact that my experimental patch uses error trapping, that is *not*
what I have in mind for the implementation. I do not want to trap errors upon
insert or copy from. Rather, I wish to implement functionality that would
allow
On Sun, 5 Feb 2006, James William Pye wrote:
On Sun, Feb 05, 2006 at 02:08:12PM -0800, Stephan Szabo wrote:
Have you considered how this might work with spec-compliant constraint
timing?
I haven't gone so far as to look into the spec, yet. [Noise of rustling
papers]
However
On Thu, 2 Feb 2006, Mark Woodward wrote:
Now, the answer, obviously, is to create multiple postgresql database
clusters and run postmaster for each logical group of databases, right?
That really is a fine idea, but
Say, in pgsql, I do this: \c newdb It will only find the database that I
On 12/9/2005 8:27 PM, Stephan Szabo wrote:
On Fri, 9 Dec 2005, Jan Wieck wrote:
On 12/8/2005 8:53 PM, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Yeah. I really don't understand it, but it appears to me to be
explicitly
different in the spec for on delete
On Fri, 9 Dec 2005, Jan Wieck wrote:
On 12/8/2005 8:53 PM, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Yeah. I really don't understand it, but it appears to me to be explicitly
different in the spec for on delete cascade even compared to the rest of
the referential actions
On Thu, 8 Dec 2005, Jan Wieck wrote:
On 12/7/2005 4:50 PM, Stephan Szabo wrote:
On Wed, 7 Dec 2005, Bruce Momjian wrote:
I had an open 8.1 item that was:
o fix foreign trigger timing issue
Would someone supply text for a TODO entry on this, as I don't think we
fixed
On Wed, 7 Dec 2005, Bruce Momjian wrote:
I had an open 8.1 item that was:
o fix foreign trigger timing issue
Would someone supply text for a TODO entry on this, as I don't think we
fixed it in 8.1.
I'd split this into two separate items now.
Fix before delete triggers on cascaded
On Tue, 15 Nov 2005 [EMAIL PROTECTED] wrote:
I don't understand why an user can't WILLINGLY (by EXPLICITLY setting an
OPTION) allow a privileged administrator to run PostGre.
Well, to start with, it increases the support costs of the product as a
whole to the community. Adding an option with
On Fri, 11 Nov 2005, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
It's even sillier than that:
test=# SELECT substring ('1234567890' FOR 4::bigint);
substring
---
(1 row)
test=# SELECT substring ('1234567890' FOR 4::int);
substring
---
On Fri, 11 Nov 2005, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
It looks to me like we should be supporting any exact numeric with scale 0
there (at least AFAICS from SQL92 and SQL03), so I don't think the current
behavior is compliant. It doesn't look like adding a numeric
On Thu, 3 Nov 2005, Simon Riggs wrote:
On Wed, 2005-11-02 at 19:12 -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Could someone please quantify how much bang we might get for what seems
like quite a lot of bucks?
I appreciate the need for speed, but the saving here
On Fri, 28 Oct 2005, Philip Yarra wrote:
Just testing pl/pgsql functions in 8.1beta4, I see failures for syntax that
works in 8.0.3. The simplest test case for this is:
The function below fails for me similarly in 8.0.3 on execution. 8.1
merely tells you at creation time.
Using bar and foo
On Wed, 19 Oct 2005, Dann Corbit wrote:
-Original Message-
From: Terry Fielder [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 19, 2005 2:05 PM
To: Dann Corbit
Cc: Tino Wildenhain; Marc G. Fournier; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org;
On Fri, 2 Sep 2005, Stephan Szabo wrote:
[Hackers now seems more appropriate]
On Thu, 1 Sep 2005, Stephan Szabo wrote:
On Tue, 23 Aug 2005, Stephan Szabo wrote:
Here's my current work in progress for 8.1 devel related to fixing the
timing issues with referential actions having
On Fri, 9 Sep 2005, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Is there a case other than a before trigger updating a row we will want to
act upon later in the statement where we'll get a row with xmax of our
transaction and cmax greater than the current command?
The greater
On Fri, 19 Aug 2005, Stephan Szabo wrote:
On Fri, 19 Aug 2005, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Is the correct answer to continue marking and running the triggers until
there are no immediate triggers left to run for this case?
Hmm ... my recollection
On Fri, 19 Aug 2005, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Is the correct answer to continue marking and running the triggers until
there are no immediate triggers left to run for this case?
Hmm ... my recollection is that we put in the concept of marking because
we
On Wed, 17 Aug 2005, Stephan Szabo wrote:
On Tue, 16 Aug 2005, Stephan Szabo wrote:
On Tue, 16 Aug 2005, Tom Lane wrote:
I think this would take some generalization of afterTriggerInvokeEvents,
which now might or might not find the target rel in the EState it's
passed
On Tue, 16 Aug 2005, Stephan Szabo wrote:
On Tue, 16 Aug 2005, Tom Lane wrote:
I think this would take some generalization of afterTriggerInvokeEvents,
which now might or might not find the target rel in the EState it's
passed, but otherwise it doesn't seem too invasive. Thoughts
On Tue, 16 Aug 2005, Tom Lane wrote:
[ redirected to -hackers ]
I wrote:
This suggests that we need a way to prevent immediate execution of
freshly queued triggers at the end of a command fired by an FK trigger.
If we could move them to the end of the trigger queue that the FK
On Wed, 27 Jul 2005, Dawid Kuroczko wrote:
Hello. I was just wondering, assume we have such tables:
CREATE TABLE data (
foo text,
somename_id integer not null references (somenames)
);
CREATE TABLE somenames (
somename_id serial PRIMARY KEY
somename text NOT NULL
);
And
On Fri, 15 Jul 2005, Hannu Krosing wrote:
What comes to Toms's May 20 argument that people would be surprised when
they select form a table whith check(i0) constraint and get out i0
then I think this is a question of education.
I potentially disagree. What are we trying to model here? Systems
On Thu, 7 Jul 2005, Stephen Frost wrote:
* Andrew - Supernews ([EMAIL PROTECTED]) wrote:
On 2005-07-07, Stephen Frost [EMAIL PROTECTED] wrote:
* truncate is not MVCC-safe.
Erm, that's why it gets a stronger lock, so I don't really see what
this has to do with it.
It's not
On Mon, 20 Jun 2005, Tom Lane wrote:
Markus Bertheau =?UTF-8?Q?=E2=98=AD?= [EMAIL PROTECTED] writes:
Maybe quote_* is not the right name, but the functionality is needed.
I don't think so --- at least not in plpgsql, which can do this already.
Just assign the value to a text variable and
On Thu, 26 May 2005, Neil Conway wrote:
I spent a little while looking into a performance issue with a large
UPDATE on a table with foreign keys. A few questions:
(1) When a PK table is updated, we skip firing the per-row UPDATE RI
triggers if none of the referenced columns in the PK table
On Thu, 26 May 2005, Stephan Szabo wrote:
On Thu, 26 May 2005, Neil Conway wrote:
(2) For per-row RI triggers of all kinds, we save the trigger under
CurTransactionContext and invoke it at the end of the current query.
There is not even overflow to disk (the report that prompted me
On Fri, 27 May 2005, Neil Conway wrote:
Stephan Szabo wrote:
Are you sure? RI_FKey_Check seems to have a section on
TRIGGER_FIRED_BY_UPDATE which seems to check if the keys are equal if the
old row wasn't part of this transaction.
Well, regardless of how RI_FKey_Check() itself works
On Thu, 26 May 2005, Stephan Szabo wrote:
On Fri, 27 May 2005, Neil Conway wrote:
Stephan Szabo wrote:
Are you sure? RI_FKey_Check seems to have a section on
TRIGGER_FIRED_BY_UPDATE which seems to check if the keys are equal if the
old row wasn't part of this transaction.
Well
On Thu, 26 May 2005, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Okay, I can't think of cases even with triggers and the like where
removing the check on equal valued rows would give appreciably different
results, but I haven't thought too hard about it.
Err, except
On Thu, 26 May 2005, Tom Lane wrote:
The thoughts I've had about special-casing RI events to save memory
have to do with the idea of lossy storage. As you accumulate more
per-row events, at some point it becomes more efficient to forget
the individual rows and just reapply the original
On Thu, 26 May 2005, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
On Thu, 26 May 2005, Tom Lane wrote:
The thoughts I've had about special-casing RI events to save memory
have to do with the idea of lossy storage.
One problem with that is that it works for the constraint
On Wed, 20 Apr 2005, Christopher Kings-Lynne wrote:
Hi,
Can you put a foreign key constraint on an array column that says that
each element of the array must match a primary key?
Not currently, because foreign keys are between directly comparable
things.
If not, is this a TODO perhaps?
On Sat, 26 Mar 2005, Palle Girgensohn wrote:
I've noticed a couple of things about using the ICU patch vs. pristine
pg-8.0.1:
- ORDER BY is case insensitive when using ICU. This might break the SQL
standard (?), but sure is nice :)
Err, I think if your system implements strcoll correctly
On Sun, 27 Mar 2005, Palle Girgensohn wrote:
--On lördag, mars 26, 2005 08.16.01 -0800 Stephan Szabo
[EMAIL PROTECTED] wrote:
On Sat, 26 Mar 2005, Palle Girgensohn wrote:
I've noticed a couple of things about using the ICU patch vs. pristine
pg-8.0.1:
- ORDER BY is case
On Fri, 25 Mar 2005, Devrim GUNDUZ wrote:
-
--
PostgreSQL 8.0.1 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC)
3.2.3 20030502 (Red Hat Linux 3.2.3-42)
1 - 100 of 487 matches
Mail list logo
