Embedded Postgres

Ognjen Blagojevic <ognjen@etf.bg.ac.rs> writes:

Is there a way to run Postgres in embedded mode? More precisely, to run
it without using TCP/IP port, and without installing as a service?

No.

regards, tom lane

Ognjen Blagojevic, 21.04.2010 17:08:

More precisely, to run it without using TCP/IP port

No

and without installing as a service?

Yes (simply run pg_ctl "manually" from the command line)

Thomas

Ognjen Blagojevic wrote:

Is there a way to run Postgres in embedded mode? More precisely, to
run it without using TCP/IP port, and without installing as a service?
I am aware of Unix-domain sockets, but is there something similar for
Windows?

on unix, as you imply, it can be run with unix domain sockets, but not
on Windows as they simply don't have this interface. and, it can be
started as an application rather than as a system service, but it still
runs as a separate process from your application(s) and in my book,
thats not really embedded.

John R Pierce wrote:

Ognjen Blagojevic wrote:

Is there a way to run Postgres in embedded mode? More precisely, to
run it without using TCP/IP port, and without installing as a service?
I am aware of Unix-domain sockets, but is there something similar for
Windows?

on unix, as you imply, it can be run with unix domain sockets, but not
on Windows as they simply don't have this interface. and, it can be
started as an application rather than as a system service, but it still
runs as a separate process from your application(s) and in my book,
thats not really embedded.

Thank you all for clarification.

Regards,
Ognjen

John R Pierce wrote:

Ognjen Blagojevic wrote:

Is there a way to run Postgres in embedded mode? More precisely, to
run it without using TCP/IP port, and without installing as a service?
I am aware of Unix-domain sockets, but is there something similar for
Windows?

on unix, as you imply, it can be run with unix domain sockets, but not
on Windows as they simply don't have this interface. and, it can be
started as an application rather than as a system service, but it still
runs as a separate process from your application(s) and in my book,
thats not really embedded.

Thank you all for clarification.

Regards,
Ognjen

Ognjen,

Is there a way to run Postgres in embedded mode? More precisely, to run it

without using TCP/IP port, and without installing as a service?
I am aware of Unix-domain sockets, but is there something similar for
Windows?

on unix, as you imply, it can be run with unix domain sockets, but not on
Windows as they simply don't have this interface. and, it can be started
as an application rather than as a system service, but it still runs as a
separate process from your application(s) and in my book, thats not really
embedded.

within Windows there is the concept of a "named pipe". You could dig into

the communication code of Postgres which puts data through the unix-socket,
and write an "named pipe" communicator. PostgreSQL would still be running in
its own process, but only accessable from within the application. Be aware:
that is an idea for a solution; it is neither included nor projected for
PostgreSQL.

Harald

--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
%s is too gigantic of an industry to bend to the whims of reality

Massa, Harald Armin wrote:

on unix, as you imply, it can be run with unix domain sockets,
but not on Windows as they simply don't have this interface.
and, it can be started as an application rather than as a
system service, but it still runs as a separate process from
your application(s) and in my book, thats not really embedded.

within Windows there is the concept of a "named pipe". You could dig
into the communication code of Postgres which puts data through the
unix-socket, and write an "named pipe" communicator. PostgreSQL would
still be running in its own process, but only accessable from within
the application. Be aware: that is an idea for a solution; it is
neither included nor projected for PostgreSQL.

I'm not sure more than one connection can be made to a named pipe, they
don't really work like sockets, so this would be a poor choice as even
an embedded database typically needs several connects from a
multithreaded application (plus maintenance connections such as autovacuum)