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 b
"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
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
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
Josh Berkus 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 industry
"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, b
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
st
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,
wi
"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:
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
On 9/18/06, 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 ...
yes, i can explain it in detail, and am willing to kick in some
documentation. it is very cool, and
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
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
+
> -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
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 4
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
"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
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
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
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 PGCLIENT
"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 wit
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
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?
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. N
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 t
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: H
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 broadca
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
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 the
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.
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
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?
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
http://www.supern
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 c
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
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 r
36 matches
Mail list logo