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
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 t
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 w
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
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 sta
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.
> >
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, 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:
>
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;
> > >
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 , it's a
.
---
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
> ---
> {""}
> {""}
> {" "}
> {""}
> {""}
> {"
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 ha
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 ha
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 ta
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:
> > > >
> &g
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
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
> gene
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.
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 "=":
> http://archives.postgresq
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 pa
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
> > >
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 ta
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?
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 referenc
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 col
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 fo
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
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
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, 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 o
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 s
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 (th
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
> &g
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 Pos
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 sa
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 whe
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
[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 "up
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?
>
&g
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
On Thu, 9 Mar 2006, Stephen Frost wrote:
> * Jonah H. Harris ([EMAIL PROTECTED]) wrote:
> > On 3/9/06, William ZHANG <[EMAIL PROTECTED]> wrote:
> > > Or should we let
> > > DROP TABLE foo CASCADE;
> > > to drop the SYNONYMS depended on the table?
> >
> > Yes, I don't see any reason not to all
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 o
On Fri, 3 Mar 2006, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > 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 b
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
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.
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 need
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
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 bt
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 red
On Sun, 26 Feb 2006, Clark C. Evans wrote:
> On Sat, Feb 25, 2006 at 10:52:48PM -0800, Stephan Szabo wrote:
> | > * Issue a warning when creating a constraint who's name is
> | > not unique within its (the constraint's) schema.
> |
> | I don't have a
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
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
> th
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, $
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"
> | > &g
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
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 volu
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"
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
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.
> > >
>
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
>
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 produ
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 PRO
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
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 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
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
> > > fas
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);
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 rustl
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
> alte
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 t
> 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 understa
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 casc
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
> >>
> >>
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 casc
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:
> 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 complian
On Fri, 11 Nov 2005, Tom Lane wrote:
> Martijn van Oosterhout 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 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
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; pgsql-general@p
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
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 fix
[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 their checks run
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 r
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
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
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
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
>
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(i>0) constraint and get out i<0
> then I think this is a question of education.
I potentially disagree. What are we trying to model here? Sys
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 wi
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
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.
>
> >
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 fu
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 hav
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
>
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, regardle
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 (
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 tab
1 - 100 of 544 matches
Mail list logo
