"Golden Liu" <[EMAIL PROTECTED]> writes:
> ... The first update DOES insert index entries into unique_key's index.
Right, but weren't you proposing to make it not do so?
regards, tom lane
---(end of broadcast)---
TIP 9: In v
On 9/18/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Jim Nasby <[EMAIL PROTECTED]> writes:
> On Sep 14, 2006, at 9:16 PM, Golden Liu wrote:
>> I try to solve this problem this way:
>> First, update the table t but DON'T update the index.
>> Next, find all the tuples updated by this command and insert
On Mon, Sep 18, 2006 at 04:17:50PM -0500, Jim C. Nasby wrote:
> On Mon, Sep 18, 2006 at 12:23:16PM -0400, [EMAIL PROTECTED] wrote:
> > I have UUID generation in core in my current implementation. In the
> > last year that I've been using it, I have already chosen twice to
> > generate UUIDs from my
Tom Lane wrote:
The scary thing about a script is the assumption that it will make all
and only the changes needed. Four-digit magic numbers are not that
uncommon in C code. I think it might be safer if we made the arbitrary
OID range for an uncommitted patch be large, say eight digits (maybe
"
Tom Dunstan <[EMAIL PROTECTED]> writes:
> [ some good arguments snipped ]
> I like the script idea much better. It wouldn't be bad to even allow
> patches to be submitted with OIDs in the high 9000 or whatever range.
> The committer responsible for committing the patch could just run the
> update
Jim C. Nasby wrote:
This pg_dump issue keeps biting us in the rear... I think at the very
least we should have a means for a dump file to tell the backend that
it's about to process a dump file generated by version XYZ. That at
least gives us the ability to handle prior version incompatibilites.
Jim C. Nasby wrote:
> 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/, sin
Gregory Stark wrote:
Those types, functions and operators that aren't used by system tables could
be created by a simple SQL script instead. It's a hell of a lot easier to
write a CREATE OPERATOR CLASS call than to get all the OIDs in in four
different include files to line up properly.
No kidd
"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
Jim C. Nasby wrote:
> On Mon, Sep 18, 2006 at 01:59:00PM -0400, Andrew Dunstan wrote:
> >
> > 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
On Mon, Sep 18, 2006 at 01:59:00PM -0400, Andrew Dunstan wrote:
>
> 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 th
Martijn van Oosterhout wrote:
Seems awfully complicated. The numbers don't mean anything, they don't
have to be contiguous. If you want to reduce the chance of conflict,
find a nice big block in unused_oids, add a random number between 0 and
100 and use that. Or squeeze yourself into a block tha
On Mon, 2006-09-18 at 16:00 -0500, Jim C. Nasby wrote:
> BTW, at a former company we used SHA1s to identify files that had been
> uploaded. We were wondering on the odds of 2 different files hashing to
> the same value and found some statistical comparisons of probabilities.
> I don't recall the de
On Mon, Sep 18, 2006 at 07:46:41PM +0100, Gregory Stark wrote:
>
> 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.
>
> Reser
Whoops, I hadn't read this far when I sent the last message on the other
thread.
Gevik Babakhani wrote:
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).
This is effectively what I ended up suggesting in the a
Andrej Ricnik-Bay wrote:
> On that note ... I haven't seen anything about translation work on
> the doc-list for the upcoming release, nor have I heard from Connie
> or Anastasios. Will there be anything happening in this regard?
What sort of anything are you hoping to see? We don't have
docume
On Mon, Sep 18, 2006 at 10:09:52PM +0100, Tom Dunstan wrote:
> Hmm. A simpler way lessen the pain might be to have a script which could
> update OIDs in your catalog files. You'd have to run it BEFORE doing a
> merge. Ie, suppose I've allocated 2978-2991 in my patch, but since then
> OIDs have b
On Mon, Sep 18, 2006 at 12:23:16PM -0400, [EMAIL PROTECTED] wrote:
> I have UUID generation in core in my current implementation. In the
> last year that I've been using it, I have already chosen twice to
> generate UUIDs from my calling program. I find it faster, as it avoids
> have to call out to
On Mon, Sep 18, 2006 at 04:00:22PM -0500, Jim C. Nasby wrote:
> BTW, at a former company we used SHA1s to identify files that had been
> uploaded. We were wondering on the odds of 2 different files hashing to
> the same value and found some statistical comparisons of probabilities.
> I don't recall
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
If you're going to yank it, please at least include a generator in
contrib.
Personally, I'd like to see at least some kind of generator in core,
with appropriate info/disclaimers in the docs. A simple random-number
generator is probably the best way to go in that regard. I think that
most people k
On Mon, Sep 18, 2006 at 02:49:23PM -0400, Pascal Meunier wrote:
> regardless of the outcome. Moreover, I'd rather be a carpet to the
> PostgreSQL developers than be cited as the cause for a security improvement
> not being made, due to having antagonized so much the developers. Please,
> consider
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
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
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
"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
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_oid
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 r
"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
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.
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 o
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 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
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-c
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 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 tra
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
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
---
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
+
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
> -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
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 duplicat
"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
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
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 th
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
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
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
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 num
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 E-mai
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.
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
[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 sor
"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 addre
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 fo
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 (<@, @>, &&)
Yes, that
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 not
-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 the
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
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
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 on
"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 wit
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 "Wi
> 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, t
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 --
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
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 exp
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/
>
-
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.
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 discu
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
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, REI
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 :(
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
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, wh
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
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. Som
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 co
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 broadcast)
"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
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 xx
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 post
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
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 (especi
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 . Th
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
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 broadcast)--
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 upd
* 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 a
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 t
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?
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 s
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".
1 - 100 of 122 matches
Mail list logo
