Lukas Kahwe Smith wrote:
Peter Eisentraut wrote:
Am Montag, 18. September 2006 09:20 schrieb Lukas Kahwe Smith:
This just reminds me, are there plans to take into account multibyte
server encodings inside the client quote function?
Huh?
Ah, I just checked the libpq docs and there seems to
Tom Lane wrote:
I see the following items standing between us and putting out 8.2beta1:
* Set client encoding based on OS environment - Peter E.
[snip]
Personally I'm willing to commit to making the VALUES-list docs and
userlock replacement code happen tomorrow. Bruce seems to be close
on
Tom Lane wrote:
I see the following items standing between us and putting out 8.2beta1:
* Set client encoding based on OS environment - Peter E.
I'm not sure whether Peter is intending to complete this item for 8.2
or not, but if it's to be done it ought to be done before we start beta.
This
Am Montag, 18. September 2006 09:20 schrieb Lukas Kahwe Smith:
This just reminds me, are there plans to take into account multibyte
server encodings inside the client quote function?
Huh?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Am Montag, 18. September 2006 01:38 schrieb Tom Lane:
* Set client encoding based on OS environment - Peter E.
This is not an item for 8.2 in my mind.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 4:
Quoth [EMAIL PROTECTED] (Tom Lane):
Christopher Browne [EMAIL PROTECTED] writes:
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Tom Lane)
wrote:
I see the following items standing between us and putting out 8.2beta1:
* AIX linking issues
This has to do with the discussion
Peter Eisentraut wrote:
Am Montag, 18. September 2006 09:20 schrieb Lukas Kahwe Smith:
This just reminds me, are there plans to take into account multibyte
server encodings inside the client quote function?
Huh?
Ah, I just checked the libpq docs and there seems to be a
PQescapeStringConn.
Am Montag, 18. September 2006 14:25 schrieb Lukas Kahwe Smith:
Peter Eisentraut wrote:
Am Montag, 18. September 2006 09:20 schrieb Lukas Kahwe Smith:
This just reminds me, are there plans to take into account multibyte
server encodings inside the client quote function?
Huh?
Ah, I just
Michael Paesold [EMAIL PROTECTED] writes:
* Set client encoding based on OS environment - Peter E.
I really hope that this change will only affect psql, not pg_dump, as Peter
wrote in 2003. I would strongly object to such a change (as much as my
voice counts). The current behavior of
Jim C. Nasby [EMAIL PROTECTED] writes:
One problem I see with userlock is that you're asking for lock ID
conflicts unless you control everything on the system that's using
userlocks.
Well, the lock IDs already include the database OID under the hood,
so you only need to control stuff within
Am Montag, 18. September 2006 15:48 schrieb Tom Lane:
So there's already an environment dependency, although it's for
something much less likely to be set than LANG. I tend to agree
that we'd better avoid having dumps depend on LANG ... wonder if
we should remove the dependency on
Peter Eisentraut wrote:
Am Montag, 18. September 2006 01:38 schrieb Tom Lane:
* Set client encoding based on OS environment - Peter E.
This is not an item for 8.2 in my mind.
OK, moved to TODO:
* Set client encoding based on the client operating system encoding
On Mon, Sep 18, 2006 at 10:10:32AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
One problem I see with userlock is that you're asking for lock ID
conflicts unless you control everything on the system that's using
userlocks.
Well, the lock IDs already include the database
Jim C. Nasby [EMAIL PROTECTED] writes:
I believe recommending that you not use locks with the first
int4 above 16k (and whatever the equivalent would be for int8) would be
a good way to do that, as it would allow for segregating locks by schema
OID.
That seems pretty content-free to me, if
Lukas,
Ah, I just checked the libpq docs and there seems to be a
PQescapeStringConn. Not sure when this was added, I think PHP does not
yet use it. I will investigate this and will make sure its used in favor
of the deprecated old PQescapeString function.
PHP driver authors and major PHP
All,
Is UserLocks a cool enough feature to be worth mentioning in the 8.2 PR?
If so, can someone explain it to me off-list? I still don't get what it
does ...
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP
-Original Message-
From: [EMAIL PROTECTED]
Yeah, I know, which is why I don't find it absolutely critical that
this make it to beta1. But one of the concerns mentioned in
the thread
is that the changes might break things for older AIX versions. If we
get it into beta1, we have a
Josh Berkus wrote:
All,
Is UserLocks a cool enough feature to be worth mentioning in the 8.2 PR?
If so, can someone explain it to me off-list? I still don't get what it
does ...
Probably not.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If
Bruce Momjian [EMAIL PROTECTED] writes:
Josh Berkus wrote:
Is UserLocks a cool enough feature to be worth mentioning in the 8.2 PR?
Probably not.
Especially not since the capability has been there right along.
regards, tom lane
---(end of
On 9/18/06, Josh Berkus josh@agliodbs.com wrote:
All,
Is UserLocks a cool enough feature to be worth mentioning in the 8.2 PR?
If so, can someone explain it to me off-list? I still don't get what it
does ...
yes, i can explain it in detail, and am willing to kick in some
documentation. it
On 9/18/06, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Josh Berkus wrote:
Is UserLocks a cool enough feature to be worth mentioning in the 8.2 PR?
Probably not.
Especially not since the capability has been there right along.
I disagree, almost nobody knows
Merlin Moncure [EMAIL PROTECTED] writes:
yes, i can explain it in detail, and am willing to kick in some
documentation.
Ah-hah, you're on the hook for docs then ;-).
I'm going to go ahead with implementing it in-core per my last proposal:
void pg_advisory_lock(int8)
On 9/18/06, Tom Lane [EMAIL PROTECTED] wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
yes, i can explain it in detail, and am willing to kick in some
documentation.
Ah-hah, you're on the hook for docs then ;-).
sure no problem. the prototypes you suggested are imo the way to go,
with two
Tom, Merlin,
As far as the PR material goes, something like advisory locks
incorporated into core would be OK, but don't make it sound like
there was nothing there before ...
ok, thats a good compromise.
Yes, although if I'm doing this for PR, I need to use language which is
standard in
Merlin Moncure [EMAIL PROTECTED] writes:
sure no problem. the prototypes you suggested are imo the way to go,
with two small considerations:
is it worth considering using the oid type instead of int4 since the
'locktag' fields are unsigned?
Hmm ... I was thinking it didn't matter, but on
Josh Berkus josh@agliodbs.com writes:
As far as the PR material goes, something like advisory locks
incorporated into core would be OK, but don't make it sound like
there was nothing there before ...
Yes, although if I'm doing this for PR, I need to use language which is
standard in the
On 9/18/06, Tom Lane [EMAIL PROTECTED] wrote:
Hmm ... I was thinking it didn't matter, but on closer look, the
int4-oid cast is implicit while the oid-int4 one is only assignment.
So you'd need to write a cast to pass an OID if we declare the functions
as taking int4. But you'll need a cast
On Mon, Sep 18, 2006 at 05:06:09PM -0400, Merlin Moncure wrote:
On 9/18/06, Tom Lane [EMAIL PROTECTED] wrote:
Hmm ... I was thinking it didn't matter, but on closer look, the
int4-oid cast is implicit while the oid-int4 one is only assignment.
So you'd need to write a cast to pass an OID if we
Jim C. Nasby [EMAIL PROTECTED] writes:
Would adding OID versions of the functions (so there'd be int8, (int4,
int4) and (oid,oid)) be overkill?
I think what it'd mostly accomplish is to create couldn't resolve
ambiguous function errors :-(
regards, tom lane
I see the following items standing between us and putting out 8.2beta1:
* Set client encoding based on OS environment - Peter E.
I'm not sure whether Peter is intending to complete this item for 8.2
or not, but if it's to be done it ought to be done before we start beta.
* The contrib/userlock
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Tom Lane) wrote:
I see the following items standing between us and putting out 8.2beta1:
* AIX linking issues
This isn't necessarily a beta-stopper, but it'd be nice to get it done
so we can be sure that any beta testing done on
On Sun, Sep 17, 2006 at 07:38:38PM -0400, Tom Lane wrote:
We have three possible choices for this: do nothing, install a
bug-compatible, allegedly-clean-room implementation in contrib:
http://archives.postgresql.org/pgsql-patches/2006-09/msg00077.php
or put a hopefully-cleaner design into
On 2006-09-18, James William Pye [EMAIL PROTECTED] wrote:
FWIW, I'm +1 on the cleaner design you suggested. While I understand the
concerns of adding features/API this late;
Adding features is one thing, breaking existing users of the code is another.
--
Andrew, Supernews
Christopher Browne [EMAIL PROTECTED] writes:
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Tom Lane)
wrote:
I see the following items standing between us and putting out 8.2beta1:
* AIX linking issues
This has to do with the discussion about shared vs static libs?
If a
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2006-09-18, James William Pye [EMAIL PROTECTED] wrote:
FWIW, I'm +1 on the cleaner design you suggested. While I understand the
concerns of adding features/API this late;
Adding features is one thing, breaking existing users of the code is
On Sun, Sep 17, 2006 at 07:38:38PM -0400, Tom Lane wrote:
* The contrib/userlock replacement issue
We have three possible choices for this: do nothing, install a
bug-compatible, allegedly-clean-room implementation in contrib:
http://archives.postgresql.org/pgsql-patches/2006-09/msg00077.php
36 matches
Mail list logo
