Merlin Moncure writes:
> On Mon, Apr 4, 2011 at 9:31 AM, Tom Lane wrote:
>> So really you should be looking at some other DBMS if you want an
>> embedded implementation. It'd be nice if PG could be all things to all
>> people, but it can't; and this is one of the things it can't be.
> That's a p
On Mon, Apr 4, 2011 at 9:31 AM, Tom Lane wrote:
> Annamalai Gurusami writes:
>> On 2 April 2011 11:17, John R Pierce wrote:
>>> what you describe is neither postgres nor SQL
>>> perhaps you should look at a storage engine like BerkeleyDB
>
>> I hope that not everybody dismisses this mail thread
Annamalai Gurusami writes:
> On 2 April 2011 11:17, John R Pierce wrote:
>> what you describe is neither postgres nor SQL
>> perhaps you should look at a storage engine like BerkeleyDB
> I hope that not everybody dismisses this mail thread because of the
> above response. We are deriving our pr
On Sun, Apr 3, 2011 at 11:43 PM, Annamalai Gurusami
wrote:
> On 2 April 2011 11:17, John R Pierce wrote:
>
>> what you describe is neither postgres nor SQL
>>
>> perhaps you should look at a storage engine like BerkeleyDB
>
> I hope that not everybody dismisses this mail thread because of the
> a
On 04/04/11 12:43, Annamalai Gurusami wrote:
> What we are trying to achieve is that a single application can work as
> an ordinary client or an embedded client.
That makes a lot of sense, and would be useful for testing too.
> I have no clue as to why you have recommended BerkeleyDB in this
> c
On 2 April 2011 11:17, John R Pierce wrote:
> what you describe is neither postgres nor SQL
>
> perhaps you should look at a storage engine like BerkeleyDB
I hope that not everybody dismisses this mail thread because of the
above response. We are deriving our product from pgsql. And since we
a
On 04/01/11 10:15 PM, Annamalai Gurusami wrote:
It is a big story, but I thought the background will help highlight
our context. Can you guys provide more information that would help us
to make informed decisions?
what you describe is neither postgres nor SQL
perhaps you should look at a stor
On 2 April 2011 03:47, John R Pierce wrote:
> how would you implement SQL without parsing, etc? Annamali asked
> specifically for an implementation of the existing client-server protocol
> without TCP/IP, and thats exactly what the Unix socket interface is.
>
Maybe a little background here
On 04/01/11 2:54 PM, Merlin Moncure wrote:
On Fri, Apr 1, 2011 at 4:47 PM, John R Pierce wrote:
On 03/31/11 9:34 AM, Annamalai Gurusami wrote:
Would it be possible to implement the client server protocol into an API
interface, without involving the TCP/IP network?
sure, done already. 'domain
On Fri, Apr 1, 2011 at 4:47 PM, John R Pierce wrote:
> On 03/31/11 9:34 AM, Annamalai Gurusami wrote:
>>
>> Would it be possible to implement the client server protocol into an API
>> interface, without involving the TCP/IP network?
>
> sure, done already. 'domain sockets', the default for local
On 03/31/11 9:34 AM, Annamalai Gurusami wrote:
Would it be possible to implement the client server protocol into an
API interface, without involving the TCP/IP network?
sure, done already. 'domain sockets', the default for local connections
that don't expressly call for localhost
--
Sent
On Thu, Mar 31, 2011 at 11:34 AM, Annamalai Gurusami
wrote:
> Hi All,
>
> I would like to know about the best approach to take for providing a merged
> model of libpq library. When I say "merged model" it means that the client
> and server would be running as a single process. A single client li
12 matches
Mail list logo
