On Sunday 07 March 2004 20:28, Michael Meskes wrote:
> On Wed, Mar 03, 2004 at 07:40:40PM +0530, Shridhar Daithankar wrote:
> > Is this fine?
> > * Allow a 'connection *' pointer to be specified instead of a string to
> > denote a connection.
> > ...
>
> I personally have no problem with this as
From: "Michael Meskes" <[EMAIL PROTECTED]>
> Why? What doesn't work? AFAIRC the AT statement does indeed allow a
> variable as connection_target.
Yeah, I was wrong there. I updated the thread test program in ecpg/test to
make use of this functionality - see patch in pgsql-patches yesterday.
L.
On Wed, Mar 03, 2004 at 07:40:40PM +0530, Shridhar Daithankar wrote:
> Is this fine?
> * Allow a 'connection *' pointer to be specified instead of a string to
> denote a connection.
> ...
I personally have no problem with this as long as it does not break
compatibility to the code we allow now.
On Wed, Mar 03, 2004 at 08:47:50AM -0500, Bruce Momjian wrote:
> > But yeah, specifying the connection by variable (be it string or
> > connection ptr) would be a definite step forward. Currently you cannot
> > write a generic function like:
> >
> > int getit(char *using_connection)
> > {
> >
Shridhar Daithankar wrote:
> Zeugswetter Andreas SB SD wrote:
> >>- Dispose names of connectiong and replace them with a pointer.
> >
> >
> > You cannot dispose the names, you can only add something to also allow pointers.
> > The names are in the ESQL/C standard.
>
> Can you point me to the sta
Zeugswetter Andreas SB SD wrote:
- Dispose names of connectiong and replace them with a pointer.
You cannot dispose the names, you can only add something to also allow pointers.
The names are in the ESQL/C standard.
Can you point me to the standards text? I am googling for it but nothing
resembl
> - Dispose names of connectiong and replace them with a pointer.
You cannot dispose the names, you can only add something to also allow pointers.
The names are in the ESQL/C standard.
Andreas
---(end of broadcast)---
TIP 2: you can get off all li
Lee Kindness wrote:
Shridhar, want to discuss this off list a bit to work through the various
options and then revent back to the list with a suitable to-do (for
discussion)?
I don't mind. Just for summary, I am listing the discussion/proposal so far on
this issue..
- Dispose names of connection
Shridhar, want to discuss this off list a bit to work through the various
options and then revent back to the list with a suitable to-do (for
discussion)?
L.
- Original Message -
From: "Shridhar Daithankar" <[EMAIL PROTECTED]>
To: "Bruce Momjian" <[EMAIL PROTECTED]>
Cc: "PostgreSQL-develo
Tom Lane wrote:
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > The reason I posted it because I didn't wanted to work on it if core is not
> > going to accept it on account of non-compliance with spec.
>
> When it comes to ecpg, Michael Meskes is the man you have to convince,
> not any of
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> The reason I posted it because I didn't wanted to work on it if core is not
> going to accept it on account of non-compliance with spec.
When it comes to ecpg, Michael Meskes is the man you have to convince,
not any of the core committee.
Oh.. By all means..Please do..
The reason I posted it because I didn't wanted to work on it if core is not
going to accept it on account of non-compliance with spec.
Is this fine?
* Allow a 'connection *' pointer to be specified instead of a string to denote
a connection.
I plan to work on it
Should I add this to the TODO list?
---
Lee Kindness wrote:
> Sort of related, I was thinking about adding some more thread-related
> code such that if a connection wasn't explicitely specified then the
> last connection SET
On Friday 27 February 2004 22:24, Lee Kindness wrote:
> Sort of related, I was thinking about adding some more thread-related
> code such that if a connection wasn't explicitely specified then the
> last connection SET or CONNECTed to for the current thread is used,
> rather than just the "last con
Sort of related, I was thinking about adding some more thread-related
code such that if a connection wasn't explicitely specified then the
last connection SET or CONNECTed to for the current thread is used,
rather than just the "last connection".
But yeah, specifying the connection by variable (be
On Friday 27 February 2004 20:54, Michael Meskes wrote:
> On Fri, Feb 27, 2004 at 04:22:33PM +0530, Shridhar Daithankar wrote:
> > How about, allowing 'connection *'? If somebody puts a 'connection *'
> > there it is used. If it is a string a name search is performed. Best of
> > both worlds.
>
> H
On Fri, Feb 27, 2004 at 04:22:33PM +0530, Shridhar Daithankar wrote:
> How about, allowing 'connection *'? If somebody puts a 'connection *' there
> it is used. If it is a string a name search is performed. Best of both
> worlds.
How shall anyone put a pointer to a connection struct inside the S
Zeugswetter Andreas SB SD wrote:
I am asking for CONNECTION being a variable of data type 'connection *' rather
than 'const char *'. That would avoid name lookups.
Is that out of spec?
Yes, but the preprocessor could still add an optimization ala 'connection *' for
the hardcoded cases (exec sql
> I am asking for CONNECTION being a variable of data type 'connection *' rather
> than 'const char *'. That would avoid name lookups.
>
> Is that out of spec?
Yes, but the preprocessor could still add an optimization ala 'connection *' for
the hardcoded cases (exec sql set connection 'myconn1'
Michael Meskes wrote:
On Mon, Feb 23, 2004 at 09:27:40PM +0530, Shridhar Daithankar wrote:
What I wonder is, do we really need to maintain that level of lookup? Can't we
just say a connection is a 'struct connection *' which should be opaque and
should not be touched or poked inside, just like PG
> I'm not sure I understand you correctly. The SQL standard says you can
> call your statement as this:
> exec sql at CONNECTION select 1;
>
> Here CONNECTION of course is a string, the name of the connection. So,
> yes, we have to maintain that list to make sure we get the right
> connection.
I
On Mon, Feb 23, 2004 at 09:27:40PM +0530, Shridhar Daithankar wrote:
> It looks like the mutex protects the connections list in connection.c. I do
> not like that from a application developers perspective.
>
> If I am developing an application and using multiple connections in multiple
> threads
22 matches
Mail list logo
