The existing server extensibilities in modern DBMSs have been
critical in our company's development of software products that
improve database performance for certain scientific computing
applications. We are planning to develop other products that will
utilize an extensible database engine, and so we would be grateful
for feedback on the following questions as they pertain to your
experience in developing PostgreSQL applications:

1. What types of extensibility (i.e., data types,
functions/methods, indexing, etc.) are available and convenient to
use in practice?
2. What types of extensibility (possibly already available in
other DBMSs) are currently missing in PostgreSQL?
3. To what extent was your choice of PostgreSQL as a development
platform based primarily on its extensibility features?

**********************************************
Eric Davies, M.Sc.
Barrodale Computing Services Ltd.
Tel: (250) 472-4372 Fax: (250) 472-4373
Web: http://www.barrodale.com
Email: eric@barrodale.com
**********************************************
Mailing Address:
P.O. Box 3075 STN CSC
Victoria BC Canada V8W 3W2

Shipping Address:
Hut R, McKenzie Avenue
University of Victoria
Victoria BC Canada V8W 3W2
**********************************************

On Jan 8, 2008 7:36 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> There is no other open source database that can compare with
> PostgreSQL's extensibility, reliability and scalability.

+1000

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Joshua D. Drake wrote:

> On Tue, 08 Jan 2008 16:28:11 -0800
> Eric Davies <eric@barrodale.com> wrote:

> > 3. To what extent was your choice of PostgreSQL as a development
> > platform based primarily on its extensibility features?
>
> There is no other open source database that can compare with
> PostgreSQL's extensibility, reliability and scalability.

AFAIK there is no other database system _at all_ that can compete with
PostgreSQL's extensibility.

On Postgres, you can create your own:
- functions (common functions; "set-returning" functions; aggregate functions)
- types
- operators
- indexing access methods (in particular, indexing for your own types)
- PL languages (i.e. you can create language handler for whatever suits
you). This means there are handlers already available for Python, Tcl,
Perl, PHP, sh, and others.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

"Joshua D. Drake" <jd@commandprompt.com> writes:

>> 2. What types of extensibility (possibly already available in
>> other DBMSs) are currently missing in PostgreSQL?
>
> None that I am aware of.

I'm sure there are some options available in some databases which Postgres
doesn't have. Usually Postgres has more choices than any of the others but
that doesn't mean that it includes the union of all of their feature sets.

You'll probably get more useful answers if you ask a more specific question.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Tuesday 08 January 2008 21:31, Gregory Stark wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
> >> 2. What types of extensibility (possibly already available in
> >> other DBMSs) are currently missing in PostgreSQL?
> >
> > None that I am aware of.
>
> I'm sure there are some options available in some databases which Postgres
> doesn't have. Usually Postgres has more choices than any of the others but
> that doesn't mean that it includes the union of all of their feature sets.
>

I guess one could include synonyms and packages as possible items we don't
have which would make us more extensible, but the uses for those tools that
can't be covered with the tools available in postgres is pretty narrow.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On 08.01.2008, at 17:36, Joshua D. Drake wrote:

>> 2. What types of extensibility (possibly already available in
>> other DBMSs) are currently missing in PostgreSQL?
>
> None that I am aware of.

Easy multi-master clustering with just two machines.

cug

--
http://www.event-s.net


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Guido Neitzer wrote:
> On 08.01.2008, at 17:36, Joshua D. Drake wrote:
>
>>> 2. What types of extensibility (possibly already available in
>>> other DBMSs) are currently missing in PostgreSQL?
>>
>> None that I am aware of.
>
> Easy multi-master clustering with just two machines.

That isn't really an extensibility argument. At least not in my mind.
Further I don't know of anyone that can "easily" do it. You either
suffer the possibility of catastrophic data loss (dolphins) or you
suffer guaranteed bank account drainage (Oracle), or you suffer the
willingness of Monopolies (MSSQL).

None of those equate to "easy".

Joshua D. Drake

>
> cug
>


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On 09.01.2008, at 00:08, Joshua D. Drake wrote:

> Did you even bother to read the page?

Actually I tried but typed it in the browser and it resolved directly
to continuent.com (which I have as a bookmark) and I wasn't aware of
the Sequoia stuff anymore and combined Contiuent with uni/cluster
directly in my mind. That was the main problem here.

After reading again a bit now, I haven't seen mentioned how many nodes
are required to have a minimum more or less safe fail-over setup.

> Great! I was just trying to show you that there was a JDBC layer
> available for multi-mastering with PostgreSQL.

When I find some time, I might dig a bit deeper in the Sequoia stuff
again. We will see. Thanks for that hint.

cug

--
http://www.event-s.net


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On 09.01.2008, at 00:14, Ow Mun Heng wrote:

>> Like, I have a situation where I need multi-master just for
>> availability. Two small servers are good enough for that. But
>> unfortunately with PostgreSQL the whole setup is a major pain in
>> the ...
>>
>
> Isn't that the reason they hire DB admins and not the run of the mill
> guy.

Isn't that more the situation where it is preferred to have a working
fail-over with as less money and work as possible?

There is just no way I (personally) can afford hiring someone to set
that up as I'm talking about something that hasn't brought a dollar
yet and will probably not for the next time ... and it is my own
project, but there is still some need for a reliable service to come
to a point where I can maybe hire someone.

cug

--
http://www.event-s.net


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Wed, 2008-01-09 at 00:21 -0700, Guido Neitzer wrote:
> On 09.01.2008, at 00:08, Joshua D. Drake wrote:

> > Great! I was just trying to show you that there was a JDBC layer
> > available for multi-mastering with PostgreSQL.
>
> When I find some time, I might dig a bit deeper in the Sequoia stuff
> again. We will see. Thanks for that hint.
>


IIRC, there was a presentation on avaiable replication solutions in one
of the pgcons. Perhaps you can search there.

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org/