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
I see two entries:
* Improve subtransaction performance (Alvaro, Itagaki Takahiro, Tom)
* Improve sub-transaction performance (Itagaki Takahiro)
Aren't they the same?
Markup: New operators for array-subset comparisons (@, @, amp;amp;)
--
Teodor Sigaev
[EMAIL PROTECTED] wrote:
... I *like* sorting by time, as it allows
the UUID to be used similar to sequence, leaving older, lesser accessed
UUIDs in the past.
and don't forget, an automatic timestamp of when a record is created might be useful for
other purposes.
Regards,
Thomas Hallgren
Gevik Babakhani wrote:
To my opinion GUIDs type need to provide the following in the database.
1. GUID type must accept the correct string format(s), with of without
extra '-'
2. GUID type must internally be stored as small as possible.
3. GUID type must be comparable with == , != , LIKE and
LIKE could come handy if someone wants to abuse the uuid datatype to
store MD5 hash values. However I am not going to implement it if there
is no need for that (assuming it will pass the acceptance test)
On Mon, 2006-09-18 at 10:06 +0200, Thomas Hallgren wrote:
Gevik Babakhani wrote:
To my
Gevik Babakhani wrote:
LIKE could come handy if someone wants to abuse the uuid datatype to
store MD5 hash values. However I am not going to implement it if there
is no need for that (assuming it will pass the acceptance test)
Perhaps providing LIKE just to encourage abuse is not such a good
Hi,
Tom Lane wrote:
Hmm ... pattern_sel already applies the operator directly to the
most_common_vals, but in this situation those aren't common enough
to help much. With such an extensive histogram it is awfully tempting
to assume that the histogram members are a representative sample, and
Magnitude comparison on the GUID as a whole makes no
sense to me.
I agree. Any kind of comparison except equality has no meaning for the
GUID. (And this is discussed before) I rather have the option to sort
and group for the sake of consistency and compatibility.
On Mon, 2006-09-18 at 11:11 +0200, Harald Armin Massa wrote:
Gevik,
uniqueness is never a guaranteed. that is according to the RFC docs.
uniqueness is never a guaranteed in the sense that there is a tiny
chance someone of the other side of the planet might generate the
same
guid.
As
Am Freitag, 15. September 2006 20:32 schrieb Tom Lane:
I've finally taken a close look at this patch, and I don't like it any
more than Peter does. The refactoring might or might not be good at its
core, but as presented it is horrid.
Joachim Wieland is in the process of reworking the
Am Sonntag, 17. September 2006 01:47 schrieb Gevik Babakhani:
The development of the uuid datatype is yet in progress...
I was wondering if I should go ahead and add a macro datatype like the
SERIAL, only this time for the uuid.
Could you do this using a domain?
--
Peter Eisentraut
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:
On Mon, 2006-09-18 at 13:20 +0200, Peter Eisentraut wrote:
Am Sonntag, 17. September 2006 01:47 schrieb Gevik Babakhani:
The development of the uuid datatype is yet in progress...
I was wondering if I should go ahead and add a macro datatype like the
SERIAL, only this time for the uuid.
On Mon, Sep 18, 2006 at 01:13:45PM +0200, Peter Eisentraut wrote:
Joachim Wieland is in the process of reworking the original feature patch
(resetting commented out parameters) in a much more compact form. But it
turns out that there are a couple of very tricky situations involving custom
Ühel kenal päeval, R, 2006-09-15 kell 19:34, kirjutas Tom Lane:
Bruce Momjian [EMAIL PROTECTED] writes:
Oh, OK, I had high byte meaning no header, but clear is better, so
0001 is 0x01, and is . But I see now that bytea does
store nulls, so yea, we would be better using
Am Montag, 18. September 2006 13:28 schrieb Gevik Babakhani:
Could you do this using a domain?
Tom had a very good point about this.
And that point was?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP
It was
Gevik Babakhani [EMAIL PROTECTED] writes:
I was wondering if I should go ahead and add a macro datatype like the
SERIAL, only this time for the uuid.
This assumes a fact not in evidence, which is that we're going to accept
a uuid-generation function as part of core. AFAIK the only
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
Am Montag, 18. September 2006 13:50 schrieb Gevik Babakhani:
It was
My question was, Could you do this using a domain?. The possible answers to
that are Yes and No, neither of which appears below, nor does domain.
Gevik Babakhani [EMAIL PROTECTED] writes:
I was wondering if I should go
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.
On Fri, 2006-09-15 at 09:16 +0800, Golden Liu wrote:
this problem
I'm sorry but I don't see any problem. Why would you want to issue that
kind of SQL statement?
Assuming you really do, why not just DELETE/re-INSERT ?
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
On Mon, 2006-09-18 at 14:23 +0200, Peter Eisentraut wrote:
Am Montag, 18. September 2006 13:50 schrieb Gevik Babakhani:
It was
My question was, Could you do this using a domain?. The possible answers
to
that are Yes and No, neither of which appears below, nor does domain.
I don't know
Ok, so what is it you need help with?
On Sep 18, 2006, at 1:24 AM, Joshua D. Drake wrote:
Jim C. Nasby wrote:
On Sun, Sep 17, 2006 at 12:32:13PM -0700, Joshua D. Drake wrote:
Tom proposed a modest roadmap type experiment a week or so ago.
I'd like to see that pursued. After all, we know 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?
Ah, I just
So I have a quick prototype of this and in fact it handles the common use case
of a paged web page sorted on non-indexed columns very well. If you have only
a small limit like most web pages often avoids external sorts and produces
results 10-20x faster or more. Obviously by raising the size of
* Tom Lane ([EMAIL PROTECTED]) wrote:
The reason for this behavior is that analyze.c attaches the CREATE TABLE
AS aliases to the targetlist (via applyColumnNames) before it processes
the ORDER BY clause. (So, order by z2 works instead.) This seems
like a bug: one would expect that the
Jim Nasby wrote:
Ok, so what is it you need help with?
see previous discussion about what is required to keep a tracker system
healthy. In particular:
. items appearing in other media need to be put in the tracker
. items entered in the tracker need to be regularly triaged, reviewed
and
Folks,
I would like to create a language translation. Is there a procedure for
that?
I notices there are several .po files. How do I compile/enable the new
language translation once I have created a new .po file?
Regards,
Gevik.
---(end of
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
Andrew Dunstan wrote:
Being slightly more abstract, we are grappling with a couple of
different kinds of objects here: discussions and decisions. The mailing
list is a very good way of having a discussion, and a wiki is IMNSHO a
poor substitute. Ditto, bulletin board, web forum, blog .
Matteo Beccati [EMAIL PROTECTED] writes:
I cannot see anything bad by using something like that:
if (histogram is large/representative enough)
Well, the question is exactly what is large enough? I feel a bit
uncomfortable about applying the idea to a histogram with only 10
entries (especially
Joachim Wieland [EMAIL PROTECTED] writes:
I have the patch almost ready in the described form, if there is any chance
it will make it into 8.2 I will clean it up and post it ASAP but Peter wrote
me that chances are close to zero and so I stopped working on it for now.
If you'd mentioned it a
I was wondering how one can avoid OID conflicts?
I was testing the uuid patch on a new download from the CVS and
I noticed that some of the OIDs I thought to be free are used by someone
else :(
Any advice?
---(end of broadcast)---
TIP 1: if
Hannu Krosing [EMAIL PROTECTED] writes:
would adding this -
first byte 0xxx field length 1 byte, exactly that value
first byte 10xx 0xx data bytes follow
first byte 110x -- x data bytes to follow
first byte 111x -- x
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:40 schrieb Gevik Babakhani:
I would like to create a language translation. Is there a procedure for
that?
http://pgtranslation.projects.postgresql.org/
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
On Mon, Sep 18, 2006 at 04:02:56PM +0200, Gevik Babakhani wrote:
I was wondering how one can avoid OID conflicts?
I was testing the uuid patch on a new download from the CVS and
I noticed that some of the OIDs I thought to be free are used by someone
else :(
Not really. At the point of
Andreas Pflug [EMAIL PROTECTED] writes:
Isn't guaranteed uniqueness the very attribute that's expected? AFAIK
there's a commonly accepted algorithm providing this.
Anyone who thinks UUIDs are guaranteed unique has been drinking too much
of the kool-aid. They're at best probably unique. Some
On Mon, 2006-09-18 at 16:32 +0200, Martijn van Oosterhout wrote:
On Mon, Sep 18, 2006 at 04:02:56PM +0200, Gevik Babakhani wrote:
I was wondering how one can avoid OID conflicts?
I was testing the uuid patch on a new download from the CVS and
I noticed that some of the OIDs I thought to be
Andrew Dunstan wrote:
Well, of course, the internet is renowned for its preponderance of
people overburdened with humility and fairness. :-)
I think if you ask the php development team the chances are high that
they will agree that I have done exactly that for the PHP todo list.
Seriously,
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
Martijn van Oosterhout wrote:
On Mon, Sep 18, 2006 at 04:02:56PM +0200, Gevik Babakhani wrote:
I was wondering how one can avoid OID conflicts?
I was testing the uuid patch on a new download from the CVS and
I noticed that some of the OIDs I thought to be free are used by someone
else :(
Stephen Frost [EMAIL PROTECTED] writes:
I'd tend to agree that it seems like a bug but I'm a little mystified as
to why an 'order by' would be desired (or allowed) for a 'create table as'
at all. Allowing it seems to imply it has some meaning.
By that logic we should disallow CLUSTER,
Am Montag, 18. September 2006 09:21 schrieb Andreas Pflug:
Isn't guaranteed uniqueness the very attribute that's expected? AFAIK
there's a commonly accepted algorithm providing this.
There are several such algorithms, which is part of the problem. If someone
could sort that out, we might get
On Mon, Sep 18, 2006 at 03:49:29PM +0200, Lukas Kahwe Smith wrote:
I agree pretty much. However I disagree that a wiki is not useful to
summarize discussion from the mailinglist. All that it needs is people
that are humble and do not push their own agendas. If necessary they
should discuss
Bruce Momjian wrote:
I would like to see some comments about AIX linking so we
don't need to
relearn this in 1-2 years.
Something like
http://archives.postgresql.org/pgsql-hackers/2006-09/msg00893.php
or something more comprehensive?
Maybe mentioning LIBPATH and -blibpath: might be good.
Thank you :)
On Mon, 2006-09-18 at 16:30 +0200, Peter Eisentraut wrote:
Am Montag, 18. September 2006 15:40 schrieb Gevik Babakhani:
I would like to create a language translation. Is there a procedure for
that?
http://pgtranslation.projects.postgresql.org/
Completely agreed. I can remove the function from the patch. The
temptation was just too high not to include the new_guid() in the
patch :)
On Mon, 2006-09-18 at 10:33 -0400, Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Isn't guaranteed uniqueness the very attribute that's
Rocco Altier wrote:
pg_regress normally tries to handle this by setting LD_LIBRARY_PATH
... does AIX use that or a similar symbol?
The make check was successful in my previous testing of the last
patch, so it appears that AIX was paying attention to
LD_LIBRARY_PATH.
Anyhow, I have updated
Tom Lane wrote:
The proposed patch to Makefile.shlib makes me gag :-( ...
It is ugly.
lying to make
about what's the purpose of a rule is seldom a good idea. Please try
as attached instead.
I will ASAP.
Also, I am *really* dubious about the change to
ecpg/test/Makefile.regress --- if
Anyone who thinks UUIDs are guaranteed unique has been drinking too much of the kool-aid.
Identifier uniqueness considerations: This document specifies three algorithms to generate UUIDs: the first leverages the unique values of 802 MAC addresses to
guarantee uniqueness, the
On Mon, 2006-09-18 at 14:26 +0100, Gregory Stark wrote:
And lastly I find the idea of putting attention into OLAP functionality
interesting. Does anyone have any ideas on where to start with that?
In SQL:2003 the OLAP functionality mostly relies on the concept of
sorted Windows over which
Albe Laurenz [EMAIL PROTECTED] writes:
Tom Lane wrote:
Also, I am *really* dubious about the change to
ecpg/test/Makefile.regress --- if that's necessary then this whole
exercise is wrong.
For a dynamic build you do not need the change.
Only a --disable-shared build will gag without it.
Tom Lane ha scritto:
Matteo Beccati [EMAIL PROTECTED] writes:
I cannot see anything bad by using something like that:
if (histogram is large/representative enough)
Well, the question is exactly what is large enough? I feel a bit
uncomfortable about applying the idea to a histogram with only
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 05:29:34PM +0200, Harald Armin Massa wrote:
I would really like PostgreSQL to include an uuid-generation function
crafted along the recommendations in rfc4122 or ISO/IEC 9834-8; so those
UUIDs have a ISO/IEC-defined uniqueness or at least a ISO/IEC-defined
extreme
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
I've done the above and now withdraw my complaints about this patch.
Excellent, thank you.
I notice however that the patch seems to have touched only about half a
dozen of the information_schema views ... shouldn't more of them
On Mon, 2006-09-18 at 10:43 -0400, Andrew Dunstan wrote:
Martijn van Oosterhout wrote:
On Mon, Sep 18, 2006 at 04:02:56PM +0200, Gevik Babakhani wrote:
I was wondering how one can avoid OID conflicts?
I was testing the uuid patch on a new download from the CVS and
I noticed that
Teodor Sigaev wrote:
I see two entries:
* Improve subtransaction performance (Alvaro, Itagaki Takahiro, Tom)
* Improve sub-transaction performance (Itagaki Takahiro)
Aren't they the same?
Yes, removed.
Markup: New operators for array-subset comparisons (@, @, amp;amp;)
Yes, that
On Mon, Sep 18, 2006 at 11:12:54AM +0200, Gevik Babakhani wrote:
Magnitude comparison on the GUID as a whole makes no
sense to me.
I agree. Any kind of comparison except equality has no meaning for the
GUID. (And this is discussed before) I rather have the option to sort
and group for the
Harald Armin Massa [EMAIL PROTECTED] writes:
They also talk about a guaranteed differentness - and as much as I
understand, they are Unique as long as the MAC-Adresses of the Network-Cards
are unique, and fall back to extremly likely when there is no network card
present.
MAC addresses are
[EMAIL PROTECTED] wrote:
On Mon, Sep 18, 2006 at 11:12:54AM +0200, Gevik Babakhani wrote:
Magnitude comparison on the GUID as a whole makes no
sense to me.
I agree. Any kind of comparison except equality has no meaning for the
GUID. (And this is discussed before) I rather have the option to
Gevik Babakhani wrote:
Actually, it would be nice to be able to reserve some. It would help
stop patch bitrot. I know Tom Dunstan wanted to do just that while he
was working on the enums patch.
Yes it would be very. If Tom Dunstan decided not to do that I would like
build such a thing.
When we was talking about optimizing 'ORDER BY .. LIMIT' with Oleg and Alvaro at
conference, we was thinking to make new executor's node - Partial Sort. And
planner may choose which nodes to use: nodeSort and nodeLimit or nodePartialSort.
--
Teodor Sigaev
Thanks for answering; I appreciate it, as well as the efforts of all the
people who contributed to this database that I now use in my projects.
However, I feel that making a decision based on the number of prior and
possible future complaints is a poor excuse to not do the right thing. A
low
Folks,
I would like to have your thoughts on a solution for the duplicate OIDs.
I wanted to apply the uuid patch on a newly download source from the
CVS. Patching and make install went just okay but make check and
initdb failed to my surprise. A quick look at duplicate_oids showed that
almost
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
On Mon, Sep 18, 2006 at 09:30:43AM -0400, Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
The reason for this behavior is that analyze.c attaches the CREATE TABLE
AS aliases to the targetlist (via applyColumnNames) before it processes
the ORDER BY clause. (So, order by z2 works
Pascal Meunier wrote:
Thanks for answering; I appreciate it, as well as the efforts of all the
people who contributed to this database that I now use in my projects.
However, I feel that making a decision based on the number of prior and
possible future complaints is a poor excuse to not do
Pascal Meunier [EMAIL PROTECTED] writes:
I asked MITRE to provide a CCE number for this issue (the CCE is a new
effort like the CVE, but for configuration issues instead of
vulnerabilities). I'll let you know if it happens.
Trying to force us to change things by getting Mitre involved is a
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
Gevik Babakhani wrote:
Folks,
I would like to have your thoughts on a solution for the duplicate OIDs.
I wanted to apply the uuid patch on a newly download source from the
CVS. Patching and make install went just okay but make check and
initdb failed to my surprise. A quick look at
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
Teodor Sigaev [EMAIL PROTECTED] writes:
When we was talking about optimizing 'ORDER BY .. LIMIT' with Oleg and Alvaro
at conference, we was thinking to make new executor's node - Partial Sort. And
planner may choose which nodes to use: nodeSort and nodeLimit or
nodePartialSort.
That's an
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
Gevik Babakhani [EMAIL PROTECTED] writes:
3. Make a small utility that goes through a patch, finds the new OIDs
and changes them back to a value specified by the committer(s).
Would this be workable?
That utility sounds AI-complete to me ...
regards, tom lane
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/19/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Montag, 18. September 2006 15:40 schrieb Gevik Babakhani:
I would like to create a language translation. Is there a procedure for
that?
http://pgtranslation.projects.postgresql.org/
On that note ... I haven't seen anything about
Gevik Babakhani [EMAIL PROTECTED] writes:
1. When using new OIDs always start from a fixed number. For example
1. This way the new OIDs are easy to recognize and the developer can
continue the work.
Reserving a range of OIDs for experimentation seems like a good idea since it
means
On Mon, 2006-09-18 at 14:36 -0400, Tom Lane wrote:
Gevik Babakhani [EMAIL PROTECTED] writes:
3. Make a small utility that goes through a patch, finds the new OIDs
and changes them back to a value specified by the committer(s).
Would this be workable?
That utility sounds AI-complete to
On Thu, 2006-09-14 at 14:16 -0400, Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Point I want to make is - all those are cool features(and might be
critical for some) but I don't think they warrant a dramatic change in
the release cycle policy ...
Any release is going
On Mon, Sep 18, 2006 at 10:33:22AM -0400, Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Isn't guaranteed uniqueness the very attribute that's expected? AFAIK
there's a commonly accepted algorithm providing this.
Anyone who thinks UUIDs are guaranteed unique has been drinking too
Simon Riggs wrote:
I'd like to get some clarity on those dates as soon as possible, if they
are significantly earlier than May. EDB is planning some major work, so
need to see whether those projects are 8.3 or 8.4 timescale.
Whatever the date, I'd like to suggest we have 2 sync points a
On Fri, Sep 08, 2006 at 15:08:18 -0400,
Andrew Dunstan [EMAIL PROTECTED] wrote:
From time to time the idea of a logical vs physical mapping for columns
has been mentioned. Among other benefits, that might allow us to do some
rearrangement of physical ordering to reduce space wasted on
On 9/18/06 2:00 PM, Tom Lane [EMAIL PROTECTED] wrote:
Pascal Meunier [EMAIL PROTECTED] writes:
I asked MITRE to provide a CCE number for this issue (the CCE is a new
effort like the CVE, but for configuration issues instead of
vulnerabilities). I'll let you know if it happens.
Trying
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)
Gregory Stark [EMAIL PROTECTED] writes:
Those types, functions and operators that aren't used by system tables could
be created by a simple SQL script instead.
Only if you don't need to know their OIDs anywhere in the C code. I'm
not certain offhand how many of the non-core objects are so
On Mon, 2006-09-18 at 14:10 -0400, Andrew Dunstan wrote:
My idea was to have a file called reserved_oids.h which would contain
lines like:
#error do not include this file anywhere
CATALOG(reserved_for_foo_module,9876) /* 2006-09-18 */
and which would be examined by the unused_oids
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
I couldn't remember if you wanted grammar/spelling nitpicks, so I
included them... sorry for the noise if you didn't want them.
#Improve performance of statistics monitoring, especially
pg_stat_activity (Tom)#
I would s/pg_stat_activity/stats_command_string/, since that's where the
actual change
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
Hi all. I don't know if here is the best place, but in: http://conference.postgresql.org/Catalog there's no link to the slides of the talks.I think that would be nice the slides there :)
[]'s- Walter
1 - 100 of 123 matches
Mail list logo
