On Mon, 2007-10-08 at 17:38 -0400, Robert Treat wrote:
> On Monday 08 October 2007 16:29, Magnus Hagander wrote:
> > The whole contrib thing confuses a lot of users. Is it included, or
> > isn't it? IMHO, that distinction need to be clear, and I thought we
> > were working (if not actively then at
On 10/8/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
> Gokulakannan Somasundaram wrote:
> > I am always slightly late in understanding things. Let me
> try
> > to understand the use of DSM. It is a bitmap index on whether all the
> tuples
> > in a particular block is visible to
On 10/8/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
>
> Gokulakannan Somasundaram wrote:
> > Hi Heikki, I am always slightly late in understanding things. Let me
> > try to understand the use of DSM. It is a bitmap index on whether all
> > the tuples in a particular block is visible to all the
On Mon, 2007-10-01 at 19:25 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > http://blogs.netapp.com/dave/2007/08/oracle-optimize.html
>
> Not a whole lot of technical content there, but pretty interesting
> nonetheless. I *think* that the issues we're seeing are largely in th
On 10/9/07, Gokulakannan Somasundaram <[EMAIL PROTECTED]> wrote:
>
>
>
> On 10/8/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> >
> > Gokulakannan Somasundaram wrote:
> > > I am always slightly late in understanding things. Let me
> > try
> > > to understand the use of DSM. It is
On Tue, Oct 09, 2007 at 08:15:35AM +0200, Magnus Hagander wrote:
> > In hindsight, all these ecpg changes should have been made between beta1
> > and beta2 when we have time to deal with the fallout, not right before
> > beta1.
This one I totally agree with.
> Or considered new features and held
"Gokulakannan Somasundaram" <[EMAIL PROTECTED]> writes:
> On 10/9/07, Gokulakannan Somasundaram <[EMAIL PROTECTED]> wrote:
>
>> A function is said to be deterministic, if it returns the same value,
>> irrespective of how many times, it is invoked. I think this definition
>> clearly puts the random
On Tue, Oct 09, 2007 at 10:00:51AM +0200, Michael Meskes wrote:
> On Tue, Oct 09, 2007 at 08:15:35AM +0200, Magnus Hagander wrote:
> > > In hindsight, all these ecpg changes should have been made between beta1
> > > and beta2 when we have time to deal with the fallout, not right before
> > > beta1.
[snip]
> In the case of User-Defined functions, the user should be defining it
> as Deterministic.
The user CAN already define his functions as
"Deterministic=IMMUTABLE"... the problem is that many of us will define
functions as immutable, when in fact they are not. And do that by
mistake... and
On 10/8/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> I had a thought a week ago. If we update the time zone database for
> future dates, and you have a future date/time stored, doesn't the time
> change when the time zone database changes.
>
> For example if I schedule an appointment in New Zeal
On Tue, Oct 09, 2007 at 08:20:45AM +0100, Simon Riggs wrote:
> On Mon, 2007-10-08 at 17:38 -0400, Robert Treat wrote:
> > On Monday 08 October 2007 16:29, Magnus Hagander wrote:
> > > The whole contrib thing confuses a lot of users. Is it included, or
> > > isn't it? IMHO, that distinction need to
> > Did it? I see nothing for txid in relesase.sgml.
>
> Right. release.sgml will be updated in batches as we near final
> release. We don't update for individual commits.
Ok. I will explain about txid for local users myself.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end
On Tue, 2007-10-09 at 10:58 +0200, Magnus Hagander wrote:
> On Tue, Oct 09, 2007 at 08:20:45AM +0100, Simon Riggs wrote:
> > On Mon, 2007-10-08 at 17:38 -0400, Robert Treat wrote:
> > > On Monday 08 October 2007 16:29, Magnus Hagander wrote:
> > > > The whole contrib thing confuses a lot of users.
On Sat, Oct 06, 2007 at 11:50:39PM -0400, Andrew Dunstan wrote:
>
>
> Andrew Dunstan wrote:
> >
> >
> >Magnus Hagander wrote:
> >>Bingo.
> >>
> >>With that, all the ECPG regression tests now pass on MSVC builds.
> >>
> >>Andrew - please enable it for the buildfarm :-)
> >>
> >>
> >>
> >
> >Yes,
Hello
I would to manage czech FAQ with mediawiky
http://www.pgsql.cz/index.php/Frequently_Asked_Questions
and automaticly transform FAQ to any format.
what is good format for you? I prefere plain html or DocBook?
Current form of F.A.Q. is little bit obsolette.
Regards
Pavel Stehule
-
Hello
I found lot of slow queries in some databases which I checked based on
advice 4.1. from FAQ,
To SELECT a random row, use:
SELECT col
FROM tab
ORDER BY random()
LIMIT 1;
It's robust and slow on bigger tables. Can we add some better solutions?
Regards
Pavel Stehule
---
I wrote:
> On 10/8/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > I had a thought a week ago. If we update the time zone database for
> > future dates, and you have a future date/time stored, doesn't the time
> > change when the time zone database changes.
> >
> > For example if I schedule an ap
Hi,
When i saw the IndexTuple structure, i saw that 13 bits are allocated
to store the size of the Values List of the IndexTuple Structure. Also the
IID(ItemId Identifier) in the Page header stores the complete size of the
IndexTuple. Can't we derive the size of the IndexTuple from the IID->le
Csaba Nagy wrote:
Can we frame a set of guidelines, or may be some test procedure, which
can declare a certain function as deterministic?
You mean postgres should check your function if it is really immutable ?
I can't imagine any way to do it correctly in reasonable time :-)
Imagine a functio
These messages from pg_ctl are not useful
$ pg_ctl -D nonexistent stop
pg_ctl: PID file "nonexistent/postmaster.pid" does not exist
Is server running?
The message should say
pg_ctl: Data Directory "nonexistent" does not exist
$ pg_ctl -D nonexistent start
postgres cannot access the server config
On 10/9/07, Gokulakannan Somasundaram <[EMAIL PROTECTED]> wrote:
>
> Hi,
> When i saw the IndexTuple structure, i saw that 13 bits are allocated
> to store the size of the Values List of the IndexTuple Structure. Also the
> IID(ItemId Identifier) in the Page header stores the complete size of
> I think you're overly pessimistic here ;-) This classification can be done
> quite
> efficiently as long as your language is "static enough". The trick is not to
> execute the function, but to scan the code to find all other functions and
> SQL
> statements a given function may possibly call
Am Dienstag, 9. Oktober 2007 schrieb Simon Riggs:
> These messages from pg_ctl are not useful
>
> $ pg_ctl -D nonexistent stop
> pg_ctl: PID file "nonexistent/postmaster.pid" does not exist
> Is server running?
>
> The message should say
> pg_ctl: Data Directory "nonexistent" does not exist
Well,
On Tue, Oct 09, 2007 at 01:09:19PM +0200, Peter Eisentraut wrote:
> Am Dienstag, 9. Oktober 2007 schrieb Simon Riggs:
> > These messages from pg_ctl are not useful
> >
> > $ pg_ctl -D nonexistent stop
> > pg_ctl: PID file "nonexistent/postmaster.pid" does not exist
> > Is server running?
> >
> > Th
On Tue, 2007-10-09 at 13:20 +0200, Magnus Hagander wrote:
> On Tue, Oct 09, 2007 at 01:09:19PM +0200, Peter Eisentraut wrote:
> > Am Dienstag, 9. Oktober 2007 schrieb Simon Riggs:
> > > These messages from pg_ctl are not useful
> > >
> > > $ pg_ctl -D nonexistent stop
> > > pg_ctl: PID file "nonexi
Trevor Talbot wrote:
Actually, I'm used to knowing how PostgreSQL does it, but looking at
things again I remember some confusion I had when first encountering
the timestamp types. I don't know what the SQL Standard says; is the
implication that "timestamp with time zone" actually stores the
lit
Am Dienstag, 9. Oktober 2007 schrieb Simon Riggs:
> On Tue, 2007-10-09 at 13:20 +0200, Magnus Hagander wrote:
> > On Tue, Oct 09, 2007 at 01:09:19PM +0200, Peter Eisentraut wrote:
> > > Well, this objection could apply to any place where a file is being
> > > opened. I'm curious how you plan to sor
4.1)
To SELECT a random row, use:
SELECT col
FROM tab
ORDER BY random()
LIMIT 1;
+ On bigger tables this solution is slow. Please, find smarter
solution on network.
4.6)
ILIKE is slow, specially on multibyte encodings. If is possible use
FULLTEXT. LIKE '%some%' is slow always
Am Dienstag, 9. Oktober 2007 schrieb Magne Mæhre:
> SQL itself doesn't say anything how the data element should be stored,
> only how it should be operated upon. It do, however,say that a
> datetime/time WITH TIME ZONE represents the time in UTC (SQL 2003,
> §4.3). All operations on the element a
Hubert recently posted his thoughts on this topic:
http://www.depesz.com/index.php/2007/09/16/my-thoughts-on-getting-random-row/
I've encountered with this problem several times in web development and
every time found out that the best (in terms of performance) solution is to
use some pseudo rando
2007/10/9, Nikolay Samokhvalov <[EMAIL PROTECTED]>:
> Hubert recently posted his thoughts on this topic:
> http://www.depesz.com/index.php/2007/09/16/my-thoughts-on-getting-random-row/
>
> I've encountered with this problem several times in web development and
> every time found out that the best (
Hi.
I'm looking at the strange phenomenon
--
C:\Program Files\PostgreSQL\8.3-beta1\bin>psql postgres postgres
Password for user postgres:
Welcome to psql 8.3beta1, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for h
On Tuesday 09 October 2007 05:55, Pavel Stehule wrote:
> Hello
>
> I would to manage czech FAQ with mediawiky
>
> http://www.pgsql.cz/index.php/Frequently_Asked_Questions
>
> and automaticly transform FAQ to any format.
>
> what is good format for you? I prefere plain html or DocBook?
>
> Current f
On Tue, 2007-10-09 at 14:25 +0200, Peter Eisentraut wrote:
> Am Dienstag, 9. Oktober 2007 schrieb Simon Riggs:
> > On Tue, 2007-10-09 at 13:20 +0200, Magnus Hagander wrote:
> > > On Tue, Oct 09, 2007 at 01:09:19PM +0200, Peter Eisentraut wrote:
> > > > Well, this objection could apply to any place
Pavel Stehule escribió:
> p.s. can we create some general F.A.Q XML format and store FAQ there?
>
> WIP Proposal:
>
>
>
>
>
> ...
> we need some tags from html:
There is a DocBook spec for FAQ lists. Actually a friend of mine was
working on converting our FAQ into that kind o
2007/10/9, Alvaro Herrera <[EMAIL PROTECTED]>:
> Pavel Stehule escribió:
>
> > p.s. can we create some general F.A.Q XML format and store FAQ there?
> >
> > WIP Proposal:
> >
> >
> >
> >
> >
> > ...
> > we need some tags from html:
>
> There is a DocBook spec for FAQ lists. Actua
On 10/9/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Independent of what any specification might say, however, the currently
> implemented behavior is clearly wrong in my mind and needs to be fixed.
I don't think it's wrong, just a particular choice. As an example,
consider an interval sche
>>> On Mon, Oct 8, 2007 at 10:48 PM, in message
<[EMAIL PROTECTED]>, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> I had a thought a week ago. If we update the time zone database for
> future dates, and you have a future date/time stored, doesn't the time
> change when the time zone database change
>>> On Tue, Oct 9, 2007 at 6:49 AM, in message
<[EMAIL PROTECTED]>, Magne
Mæhre <[EMAIL PROTECTED]> wrote:
>
> Interestingly, if you cast a TIMESTAMP WITH TIME ZONE to a character
> value, it should be converted with the _original_ time zone value
(SQL
> 2003, *5.8) _unless_ you specify "AT LO
Am Dienstag, 9. Oktober 2007 schrieb Trevor Talbot:
> I don't think it's wrong, just a particular choice. As an example,
> consider an interval scheduling system that handles everything in
> absolute time (UTC), but uses local time as a convenience.
We are not considering an interval scheduling s
On Tue, 2007-10-09 at 14:25 +0200, Peter Eisentraut wrote:
> I believe, however, that this approach is wrong. The "real error", as you
> put
> it, is the one reported by the kernel -- by definition. Everything else is
> at best a "hint".
Are you objecting to making the wording of the hint/er
Csaba Nagy wrote:
You mean postgres should check your function if it is really immutable ?
I can't imagine any way to do it correctly in reasonable time :-)
I would say that in the general case it's analogous to the halting
problem, not solvable at all let alone in any reasonable time.
On Mon, 8 Oct 2007 20:02:56 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> The money data type has been deprecated for years. It is completely non
> standard and essentially duplicative of numeric/decimal. What is the
> point?
It may be deprecated (maybe not) and it may have drawbacks but it
Magnus Hagander wrote:
(Hint: if you don't put the PlatformSDK
directories first in the INCLUDE and LIB lists bad and inexplicable
things can happen.)
Pick up the latest version of run_build.pl in CVS if you want to run
this in your buildfarm animal now.
A release will be forthcoming very
Florian G. Pflug wrote:
I think you're overly pessimistic here ;-) This classification can be
done quite efficiently as long as your language is "static enough".
The trick is not to execute the function, but to scan the code to find
all other functions and SQL statements a given function ma
On Tue, 2007-10-09 at 11:22 -0400, Andrew Dunstan wrote:
>
> Csaba Nagy wrote:
> > You mean postgres should check your function if it is really immutable ?
> > I can't imagine any way to do it correctly in reasonable time :-)
> I would say that in the general case it's analogous to the halting
>
On Tue, Oct 09, 2007 at 05:04:39PM +0200, Peter Eisentraut wrote:
> We are not considering an interval scheduling system, we are considering a
> database system. Such a system should have the basic property that if you
> store A, it will read out as A. The money type is similarly buggy: if you
Andrew Dunstan wrote:
Florian G. Pflug wrote:
I think you're overly pessimistic here ;-) This classification can be done
quite efficiently as long as your language is "static enough". The trick is
not to execute the function, but to scan the code to find all other
functions and SQL statements a
On Tue, 9 Oct 2007 11:26:16 -0400
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
> On Mon, 8 Oct 2007 20:02:56 -0700
> "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> > The money data type has been deprecated for years. It is completely
> > non standard and essentially duplicative of numeric/decimal
"Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
> Hubert recently posted his thoughts on this topic:
> http://www.depesz.com/index.php/2007/09/16/my-thoughts-on-getting-random-row/
>
> I've encountered with this problem several times in web development and
> every time found out that the best (i
Am Dienstag, 9. Oktober 2007 schrieb Simon Riggs:
> On Tue, 2007-10-09 at 14:25 +0200, Peter Eisentraut wrote:
> > I believe, however, that this approach is wrong. The "real error", as
> > you put it, is the one reported by the kernel -- by definition.
> > Everything else is at best a "hint".
>
>
OS: Windows XP Pro SP2
CPU: AMD Athlon 64 3500+
RAM: 2GB
DB: PostgreSQL 8.3beta1, compiled by Visual C++ build 1400
I've come to the conclusion that it seems like a deadlock occurs when
dropping a column in a table the same moment that table is autovacuumed.
Example:
ALTER TABLE bondetail DRO
[EMAIL PROTECTED] (Alvaro Herrera) writes:
> Pavel Stehule escribió:
>
>> p.s. can we create some general F.A.Q XML format and store FAQ there?
>>
>> WIP Proposal:
>>
>>
>>
>>
>>
>> ...
>> we need some tags from html:
>
> There is a DocBook spec for FAQ lists. Actually a friend
[Note: Cc list trimmed as everyone is probably on the list anyway]
On Tue, 9 Oct 2007 09:02:09 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> However, keep in mind that I really don't care if Money is deprecated
> or not. I do care that the docs say it is, and it may not be. :)
Understood.
2007/10/9, Gregory Stark <[EMAIL PROTECTED]>:
> "Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
>
> > Hubert recently posted his thoughts on this topic:
> > http://www.depesz.com/index.php/2007/09/16/my-thoughts-on-getting-random-row/
> >
> > I've encountered with this problem several times in we
Deblauwe Gino wrote:
> OS: Windows XP Pro SP2
> CPU: AMD Athlon 64 3500+
> RAM: 2GB
> DB: PostgreSQL 8.3beta1, compiled by Visual C++ build 1400
>
> I've come to the conclusion that it seems like a deadlock occurs when
> dropping a column in a table the same moment that table is autovacuumed.
>
>
Am Dienstag, 9. Oktober 2007 schrieb D'Arcy J.M. Cain:
> + Due to locale changes this type may have problems with dump and
> + restore and care should be taken.
With respect, this kind of advice is useless. What are the problems, when do
they occur, and what should be done about them? We
Trevor Talbot wrote:
> I wrote:
> > On 10/8/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > > I had a thought a week ago. If we update the time zone database for
> > > future dates, and you have a future date/time stored, doesn't the time
> > > change when the time zone database changes.
> > >
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I don't see how timing has anything to do with this. You could have
> > added it between beta1 and beta2 after sufficient hackers discussion.
>
> Uh, it *was* after beta1.
Oh, so it didn't hold up beta1 --- that's good.
--
Bruc
On Tue, 9 Oct 2007 19:02:38 +0200
Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Am Dienstag, 9. Oktober 2007 schrieb D'Arcy J.M. Cain:
> > + Due to locale changes this type may have problems with dump and
> > + restore and care should be taken.
>
> With respect, this kind of advice is useles
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I don't see how timing has anything to do with this. You could have
added it between beta1 and beta2 after sufficient hackers discussion.
Uh, it *was* after beta1.
Oh, so it didn't hold up
>>> On Tue, Oct 9, 2007 at 12:11 PM, in message
<[EMAIL PROTECTED]>, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Trevor Talbot wrote:
>>
>> Actually, I'm used to knowing how PostgreSQL does it, but looking at
>> things again I remember some confusion I had when first encountering
>> the timestamp
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> That said, I wonder if there is another answer to this question.
> Perhaps the functions in cash.c can be pulled out and made into
> external functions that can be fed an int (long) and output the desired
> format. That way we could use the existi
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>> Tom Lane wrote:
>>
>>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>>
I don't see how timing has anything to do with this. You could have
added it between beta1 and beta2 after sufficient hackers
discussion.
>>> Uh, i
On Tue, Oct 09, 2007 at 06:40:23PM +0200, Pavel Stehule wrote:
> It needs always seq scan :(, and take space on buffer cache. Solution
> based on random generated PK are much faster. I collaborate with one
> my customer. He shows random products from 10K products on every page
> of one eShop. And h
2007/10/9, Martijn van Oosterhout <[EMAIL PROTECTED]>:
> On Tue, Oct 09, 2007 at 06:40:23PM +0200, Pavel Stehule wrote:
> > It needs always seq scan :(, and take space on buffer cache. Solution
> > based on random generated PK are much faster. I collaborate with one
> > my customer. He shows random
On Thu, 2007-10-04 at 17:33 -0400, Alvaro Herrera wrote:
> Simon Riggs escribió:
>
> > Seems like we don't need to mess with the deadlock checker itself.
> >
> > We can rely on the process at the head of the lock wait queue to sort
> > this out for us. So all we need do is look at the isAutovacuu
Pavel Stehule wrote:
> 4.1)
>
> To SELECT a random row, use:
> SELECT col
> FROM tab
> ORDER BY random()
> LIMIT 1;
>
> + On bigger tables this solution is slow. Please, find smarter
> solution on network.
>
Well, give me a better example that works.
> 4.6)
>
> ILIKE is slow,
Kevin Grittner wrote:
> Probably, but we need a lot more than that to conform to the standard
> and to avoid surprising behavior. The first of the two statements
> below is valid ANSI syntax to add one day to the current moment.
That's the lack of standard interval support, which is an entirely
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>
> >>> I don't see how timing has anything to do with this. You could have
> >>> added it between beta1 and beta2 after sufficient hackers discussion.
> >>>
Jan Wieck wrote:
> > I don't see how timing has anything to do with this. You could have
> > added it between beta1 and beta2 after sufficient hackers discussion.
> > Doing it the way you did with no warning, right before beta, and then
> > leaving is the worse of all times. I am surprised we ar
I'm working on some code for pgInstaller that will check the locale and
encoding selected by the user are a valid combination.
The changes recently added to initdb (which highlighted the UTF-8 issue
on Windows that Tom posted about) appear to only allow the default
encoding for the locale to be se
Bruce Momjian wrote:
Andrew Dunstan wrote:
Can somebody please explain to me what beta means if you can commit new
stuff after it has been declared?
We allow /contrib to be more lax about beta changes.
I think we should be looking long and hard at that. I can't see any
justi
Bruce Momjian wrote:
> Andrew Dunstan wrote:
>>
>> Bruce Momjian wrote:
>>> Tom Lane wrote:
>>>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't see how timing has anything to do with this. You could have
> added it between beta1 and beta2 after sufficient hackers disc
Bruce Momjian wrote:
>> Can somebody please explain to me what beta means if you can commit new
>> stuff after it has been declared?
>
> We allow /contrib to be more lax about beta changes.
Why? When people were complaining about not being able to use TSearch
because their ISPs wouldn't install
Dave Page wrote:
> Bruce Momjian wrote:
> >> Can somebody please explain to me what beta means if you can commit new
> >> stuff after it has been declared?
> >
> > We allow /contrib to be more lax about beta changes.
>
> Why? When people were complaining about not being able to use TSearch
> bec
Magnus Hagander wrote:
> Andrew Dunstan wrote:
>>
>> Bruce Momjian wrote:
>>> Tom Lane wrote:
>>>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't see how timing has anything to do with this. You could have
> added it between beta1 and beta2 after sufficient hackers
On 10/9/2007 1:06 AM, Bruce Momjian wrote:
Jan Wieck wrote:
On 10/8/2007 1:34 PM, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Marko Kreen wrote:
>>> Because of the bad timing it would have been -core call anyway
>>> whether it gets in or not so Jan asked -core directly. Tha
Bruce Momjian wrote:
> Dave Page wrote:
>> Bruce Momjian wrote:
Can somebody please explain to me what beta means if you can commit new
stuff after it has been declared?
>>> We allow /contrib to be more lax about beta changes.
>> Why? When people were complaining about not being able to
2007/10/9, Bruce Momjian <[EMAIL PROTECTED]>:
> Pavel Stehule wrote:
> > 4.1)
> >
> > To SELECT a random row, use:
> > SELECT col
> > FROM tab
> > ORDER BY random()
> > LIMIT 1;
> >
> > + On bigger tables this solution is slow. Please, find smarter
> > solution on network.
> >
>
>
Pavel Stehule wrote:
> 2007/10/9, Bruce Momjian <[EMAIL PROTECTED]>:
> > Pavel Stehule wrote:
> > > 4.1)
> > >
> > > To SELECT a random row, use:
> > > SELECT col
> > > FROM tab
> > > ORDER BY random()
> > > LIMIT 1;
> > >
> > > + On bigger tables this solution is slow. Please, fin
Bruce Momjian wrote:
> Dave Page wrote:
>> Bruce Momjian wrote:
Can somebody please explain to me what beta means if you can commit new
stuff after it has been declared?
>>> We allow /contrib to be more lax about beta changes.
>> Why? When people were complaining about not being able to
On 10/9/2007 4:22 PM, Bruce Momjian wrote:
Jan Wieck wrote:
> I don't see how timing has anything to do with this. You could have
> added it between beta1 and beta2 after sufficient hackers discussion.
> Doing it the way you did with no warning, right before beta, and then
> leaving is the wo
2007/10/9, Bruce Momjian <[EMAIL PROTECTED]>:
> Pavel Stehule wrote:
> > 2007/10/9, Bruce Momjian <[EMAIL PROTECTED]>:
> > > Pavel Stehule wrote:
> > > > 4.1)
> > > >
> > > > To SELECT a random row, use:
> > > > SELECT col
> > > > FROM tab
> > > > ORDER BY random()
> > > > LIMIT 1;
Pavel Stehule wrote:
> > > Better universal solution doesn't exist. Exists only unelegant
> > > solutions - but mutch faster.
> > >
> > > SELECT id, ...
> > >FROM data
> > > WHERE id = ANY(ARRAY(
> > >SELECT (random()*:max_id)::int
> > > FROM
Jan Wieck wrote:
> On 10/9/2007 4:22 PM, Bruce Momjian wrote:
> > Jan Wieck wrote:
> >> > I don't see how timing has anything to do with this. You could have
> >> > added it between beta1 and beta2 after sufficient hackers discussion.
> >> > Doing it the way you did with no warning, right before
On 10/9/2007 5:13 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 10/9/2007 4:22 PM, Bruce Momjian wrote:
> Jan Wieck wrote:
>> > I don't see how timing has anything to do with this. You could have
>> > added it between beta1 and beta2 after sufficient hackers discussion.
>> > Doing it the way yo
Dave Page wrote:
> Is there any reason not to accept other combinations that setlocale()
> is happy with?
setlocale() sets the locale. How does it "accept" a "combination"?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
> > >
> >
> > ok. I accept it. Can be some note there? Not this strange select.
>
> Well, with 8.3 having this be faster I am thinking we should wait to see
> if the hacks are needed.
>
difference, on 10K lines (on small think table)
postgres=# select * from test where i = any(array(select
(rando
Peter Eisentraut wrote:
> Dave Page wrote:
>> Is there any reason not to accept other combinations that setlocale()
>> is happy with?
>
> setlocale() sets the locale. How does it "accept" a "combination"?
>
setlocale(LC_CTYPE, "English_United Kingdom.65001")
will return null (and not change an
Andrew Dunstan wrote:
Magnus Hagander wrote:
(Hint: if you don't put the PlatformSDK directories first in the
INCLUDE and LIB lists bad and inexplicable things can happen.)
Pick up the latest version of run_build.pl in CVS if you want to run
this in your buildfarm animal now.
A release
On Tue, 2007-10-09 at 17:13 -0400, Bruce Momjian wrote:
> I go back to my original question, do you understand the process that
> has to be followed for patch submission/application, and that it
> applies to all of us, including you?
I think you're braking a little hard here. Nothing bad has happ
Pavel Stehule wrote:
> > > >
> > >
> > > ok. I accept it. Can be some note there? Not this strange select.
> >
> > Well, with 8.3 having this be faster I am thinking we should wait to see
> > if the hacks are needed.
> >
>
> difference, on 10K lines (on small think table)
>
> postgres=# select *
Simon Riggs wrote:
That close to
release, only Core members should be doing that and Jan is Core.
My understanding (not being a member :-) ) is that Core is an
administrative group, not a group of committers. Some members of Core
are committers, some not, some committers are in Core, s
On Tue, 2007-10-09 at 17:55 -0400, Andrew Dunstan wrote:
> Simon Riggs wrote:
> > That close to
> > release, only Core members should be doing that and Jan is Core.
> >
> My understanding (not being a member :-) ) is that Core is an
> administrative group, not a group of committers. Some members
On Tue, 09 Oct 2007 17:55:48 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
>
> Simon Riggs wrote:
> > That close to
> > release, only Core members should be doing that and Jan is Core.
> >
> >
> >
>
> My understanding (not being a member :-) ) is that Core is an
> administrative group,
Andrew Dunstan wrote:
>
>
> Simon Riggs wrote:
> > That close to
> > release, only Core members should be doing that and Jan is Core.
> >
> >
> >
>
> My understanding (not being a member :-) ) is that Core is an
> administrative group, not a group of committers. Some members of Core
> are c
Simon Riggs wrote:
> On Tue, 2007-10-09 at 17:55 -0400, Andrew Dunstan wrote:
>
>> Simon Riggs wrote:
>>> That close to
>>> release, only Core members should be doing that and Jan is Core.
>>>
>
>> My understanding (not being a member :-) ) is that Core is an
>> administrative group, not a group
On Wed, 2007-10-10 at 00:19 +0200, Magnus Hagander wrote:
> Simon Riggs wrote:
> > On Tue, 2007-10-09 at 17:55 -0400, Andrew Dunstan wrote:
> >
> >> Simon Riggs wrote:
> >>> That close to
> >>> release, only Core members should be doing that and Jan is Core.
> >>>
> >
> >> My understanding (not b
Simon Riggs wrote:
> On Wed, 2007-10-10 at 00:19 +0200, Magnus Hagander wrote:
>> Simon Riggs wrote:
>>> On Tue, 2007-10-09 at 17:55 -0400, Andrew Dunstan wrote:
>>>
Simon Riggs wrote:
> That close to
> release, only Core members should be doing that and Jan is Core.
>
My unde
1 - 100 of 127 matches
Mail list logo
