Andrew Dunstan <[EMAIL PROTECTED]> writes:
> How expensive is this going to be, especially for huge numbers of rows?
Certainly cheaper than firing a per-row trigger.
> Would it be done for all queries, or just those with a per statement
> trigger, or only when explicitly requested?
Just when t
Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
If there was more information than the tuplestore could keep in memory,
then a TIDstore might be faster, but only if it resulted in reading from
the heap sequentially, or very near it.
That's easily arranged, use a bitmap in
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> If there was more information than the tuplestore could keep in memory,
> then a TIDstore might be faster, but only if it resulted in reading from
> the heap sequentially, or very near it.
That's easily arranged, use a bitmap indexing data structure.
I
Jim C. Nasby wrote:
On Sun, May 21, 2006 at 02:58:17PM -0700, Josh Berkus wrote:
Actually, porting TSQL to PL/pgSQL would be very hard. I speak as an expert
TSQL developer. For example, most data manipulation in TSQL is done through
updatable cursors, something we don't currently support.
OK, I created a "trigger" section and moved "referential integrity"
under "SQL commands".
---
Jim C. Nasby wrote:
> On Mon, May 22, 2006 at 03:11:14PM -0400, Bruce Momjian wrote:
> > Martijn van Oosterhout wrote:
> > -- Star
On Mon, May 22, 2006 at 03:14:18PM -0400, Alvaro Herrera wrote:
> Martijn van Oosterhout wrote:
> > On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
> > > > CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
> > > > ON table FOR EACH STATEMENT
> > > > EXECUTE PROCEDURE
On Mon, May 22, 2006 at 03:11:14PM -0400, Bruce Momjian wrote:
> Martijn van Oosterhout wrote:
> -- Start of PGP signed section.
> > On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
> > > > CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
> > > > ON table FOR EACH STATEM
On Mon, May 22, 2006 at 08:45:07PM +0200, Martijn van Oosterhout wrote:
> On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
> > > CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
> > > ON table FOR EACH STATEMENT
> > > EXECUTE PROCEDURE funcname ( arguments )
> >
>
Martijn van Oosterhout wrote:
> On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
> > > CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
> > > ON table FOR EACH STATEMENT
> > > EXECUTE PROCEDURE funcname ( arguments )
> >
> > And that doesn't give you any informatio
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
> > > CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
> > > ON table FOR EACH STATEMENT
> > > EXECUTE PROCEDURE funcname ( arguments )
> >
> > And that
On Mon, May 22, 2006 at 10:41:59AM -0500, Jim C. Nasby wrote:
> > CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
> > ON table FOR EACH STATEMENT
> > EXECUTE PROCEDURE funcname ( arguments )
>
> And that doesn't give you any information on the rows that were
> modified. Other
On Mon, May 22, 2006 at 05:06:47PM +0200, Martijn van Oosterhout wrote:
> On Mon, May 22, 2006 at 10:00:22AM -0500, Jim C. Nasby wrote:
> > > T-SQL has statement-level triggers, and they get used a lot (some big
> > > apps
> > > ONLY put code in triggers). Statement-level triggers are very effici
On 5/22/06, Martijn van Oosterhout wrote:
On Mon, May 22, 2006 at 10:00:22AM -0500, Jim C. Nasby wrote:
> > T-SQL has statement-level triggers, and they get used a lot (some big apps
> > ONLY put code in triggers). Statement-level triggers are very efficient for
> > maintaining aggregates; the c
On Mon, May 22, 2006 at 10:00:22AM -0500, Jim C. Nasby wrote:
> > T-SQL has statement-level triggers, and they get used a lot (some big apps
> > ONLY put code in triggers). Statement-level triggers are very efficient for
> > maintaining aggregates; the closest PG has are rewrite rules.
>
> Yeah
On Sun, May 21, 2006 at 02:58:17PM -0700, Josh Berkus wrote:
> Mischa,
>
> > Somebody earlier was mentioning, why no automatic transformer from
> > Transact-SQL to PLPGSQL (maybe with a bunch of glue routines). The grammar
> > is not a problem, though you have to wonder at all the wired-in keyword
On Fri, May 19, 2006 at 01:03:08PM -0700, Mischa Sandberg wrote:
> >On Thursday 18 May 2006 12:38, Josh Berkus wrote:
> >>Personally, I'd go after MSSQL before I bothered with MySQL. Sure, let's
> >>make *migration* easier for those who wake up and smell the BS, but
> >>migration can (and probabl
Mischa,
> Somebody earlier was mentioning, why no automatic transformer from
> Transact-SQL to PLPGSQL (maybe with a bunch of glue routines). The grammar
> is not a problem, though you have to wonder at all the wired-in keywords
> (T-SQL always felt like COBOL).
Actually, porting TSQL to PL/pgSQL
On Thursday 18 May 2006 12:38, Josh Berkus wrote:
Personally, I'd go after MSSQL before I bothered with MySQL. Sure, let's
make *migration* easier for those who wake up and smell the BS, but
migration can (and probably should) be one-way.
Somebody earlier was mentioning, why no automatic tran
18 matches
Mail list logo
