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 long as it
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)
{
EXEC SQL
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.
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.
- 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
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
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 standards text?
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
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
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.
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 the core
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-development
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
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
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
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
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';
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
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 SQL
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.
How shall
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, I
Hi all,
I was just going thr. the ecpg sources checking for thread safety.
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
22 matches
Mail list logo
