Subject | Re: [ib-support] Re: Features and Comparisons to PostgreSQL |
---|---|
Author | David Jencks |
Post date | 2002-12-15T00:55:44Z |
On 2002.12.14 15:42:31 -0500 Ubaidullah Nubar <ubaidullahnubar@...>
wrote:
without a transaction manager, which ususally (as in the xa spec)
communicates by a different channel than the application program. So, I
don't think an sql "prepare" statement is plausible.
However, note that you can use the internal firebird transaction manager to
do 2pc transparently when you do work on several firebird databases
accessed through the same connection. My understanding is that in this
case "commit" runs the 2pc protocol on all participating databases
automatically.
david jencks
wrote:
> --- In ib-support@yahoogroups.com, David Jencks <davidjencks@d...>I think you are correct. In general I don't think 2pc is at all useful
> wrote:
> > On 2002.12.14 08:34:17 -0500 Pavel Cisar wrote:
> > > Hi,
> > >
> > > Just few corrections to otherwise very precise Danile's answer...
> > >
> > > On 14 Dec 2002 at 8:48, Daniel Rail wrote:
> > >
> > > > > 1. Concurrent Transactions
> > >
> > > > If this means more than one transaction per connection, then
> yes.
> > > > But, if this means a transaction within another one, then no.
> FB 1.5
> > > > will support SAVE POINTS which is part of SQL-99.
> > >
> > > IB/FB uses the same multigenerational architecture as PostgreSQL
> > > (actually, IB has it first). You have concurrent transactions in
> read
> > > committed, repeatable read and serializable isolation levels (no
> dirty
> > > read) with option to precisely specify the access level to
> individual
> > > tables (table reservation). Multiple independent transactions per
> > > connection. No nested transactions. Support for savepoints in FB
> 1.5.
> > >
> > > > > 4. Unicode support
> > >
> > > > Yes it does. The only place where it's not fully supported and
> it's
> > > > when creating your WHERE clause, Firebird has a hard time
> coping with
> > > > the special characters in the search string. Other than that,
> it
> > > > works.
> > >
> > > ??? You can specify a character set for literals.
> > >
> > > > > 5. Schemas
> > >
> > > Namespaces ? No, but it's planned feature.
> > >
> > > > > 7. Cancel a query asynchronously
> > >
> > > Not in FB, but in IB since v6.5
> > >
> > > > > 8. Boolean field
> > > > It's being talked about and a possibility for FB 1.5(I can't
> say for
> > > > sure)
> > >
> > > You can easily substitute it with domains. Direct support for
> boolean
> > > datatype is in IB 7 and it's in FB 1.5
> > >
> > > > > 10. User defined types
> > > > FB has domains. But, if this means that the user could define a
> > > > datatype that is non-existent in FB, i.e. GUID, then no.
> > >
> > > No support for user defined operators etc. like in PostgreSQL.
> > >
> > > > > 13. Functions for default value of columns
> > > > Not that I'm aware of.
> > >
> > > Just literals, but you can use before insert triggers for that
> purpose.
> > >
> > > > > 14. Regular expression support
> > > > Yes. You use the LIKE in your WHERE clause.
> > >
> > > Wildcard masks with LIKE operator, but no regular expressions
> (yet).
> > >
> > > > > 16. LIMIT keyword
> > > > FB has the FIRST keyword to limit the number of rows returns.
> > >
> > > Yep, FIRST and SKIP, even in subqueries.
> > >
> > > > > 18. Indexes on functions
> > > > Yes it's possible. You specify the position of the returned
> column in
> > > > your ORDER BY.
> > >
> > > You probably mean expression indices. No, they are not (yet)
> supported.
> > >
> > > But don't forget FB advantages over PostgreSQL:
> > >
> > > - more compact server (1.5MB), smaller footprint
> > > - almost zero configuration and maintenance
> > > - process per client (classic) and thread per client
> (superserver)
> > > architecture (PG has just classic).
> > > - internal garbage collection thread (no external VACUUM)
> > > - far better Windows port :-)
> > > - embedded server
> > > - far better than PG for scalable vertical solutions (from
> personal PDA
> > > to SMP servers handling 3000 concurrent users)
> > > - 15+ years of successful world-wide usage in enterprise and
> mission-
> > > critical solutions
> > > - selectable stored procedures (yep, PG 7.3 got them too)
> > > - much better user's and developer's community :-)
> >
> > You left out
> > full two phase commit support, and with JayBird, nearly full XA
> transaction
> > support
>
> Thanks for the reply, David. From what I gather, two phase committed
> is not supported via SQL, need to use API for that. Please correct me
> if I am wrong.
without a transaction manager, which ususally (as in the xa spec)
communicates by a different channel than the application program. So, I
don't think an sql "prepare" statement is plausible.
However, note that you can use the internal firebird transaction manager to
do 2pc transparently when you do work on several firebird databases
accessed through the same connection. My understanding is that in this
case "commit" runs the 2pc protocol on all participating databases
automatically.
david jencks
>
> Thanks & Regards,
> Ubaidullah Nubar,
> C55, CPD2.1+LPM,
> ASP,PHP - CodeCharge
> PB+PFC
>
> >
> > david jencks
> >
> > >
> > > Best regards
> > > Pavel Cisar
> > > http://www.ibphoenix.com
> > > For all your upto date Firebird and
> > > InterBase information
> > >
> > >
> > >
> > > To unsubscribe from this group, send an email to:
> > > ib-support-unsubscribe@egroups.com
> > >
> > >
> > >
> > > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> > >
> > >
> > >
> > >
> > >
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>