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.
Or considered new features and held back for 8.4. Not picking on Michael, but
the resemblance to the /contrib discussion is striking. Ecpg
Right. My thought is still that if it isn't good enough for core, it
shouldn't be in contrib. If it *is* good enough, and we want it, we
should accept that it came in long after freeze and put it in core
anyway. If it *isn't*, then it should be on pgfoundry and be moved into
core when
(1) we've always been laxer about contrib than the core code,
While that appears to be true, I think
(a) there is no technical reason allowing us to do that, and
(b) most people don't seem to like it.
I will even go so far as to say there are technical reasons not to do it. I
beleive
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 least
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 all the
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 backends,
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 the
NFS
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 a bitmap index on
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 back
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 function
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.
This
[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 Zealand
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 be
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 of
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. Is it
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, when I have had a chance to test
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 appointment in
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
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
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
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 the
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. If
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, this
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?
The message should
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
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
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 sort out
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 are
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
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 (in
Hi.
I'm looking at the strange phenomenon
--
C:\Program Files\PostgreSQL\8.3-beta1\binpsql 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
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 form of
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 where a
Pavel Stehule escribió:
p.s. can we create some general F.A.Q XML format and store FAQ there?
WIP Proposal:
faq name = . language =
entry number=1.1.1
query/query
ansver
...
we need some tags from html: pbraibullitable
There is a DocBook spec for FAQ lists.
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:
faq name = . language =
entry number=1.1.1
query/query
ansver
...
we need some tags from html:
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
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 changes.
For
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 LOCAL.
A
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
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/error
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
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 is
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
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 may
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. What
is
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 (in terms
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.
Are you
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
[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:
faq name = . language =
entry number=1.1.1
query/query
ansver
...
we need some tags from html: pbraibullitable
[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 web development
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.
Example:
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.
For example if
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.
--
Bruce
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 useless. What
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 types. I don't
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 existing int
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, it *was* after beta1.
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 he
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 isAutovacuum flag on
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, specially on
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.
Uh, it *was* after
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 are not
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
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
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 discussion.
Uh, it *was*
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
because their
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
discussion.
Uh, it *was*
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. That's
my
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 use TSearch
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.
Well, give me a better
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, find smarter
solution on
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 use TSearch
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 worse
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;
+ On bigger tables this
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 generate_series(1,20)))
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 beta, and then
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 you did
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
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
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 anything)
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
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 * from test where i =
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,
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 of Core
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, not a group of
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 committers, some
1 - 100 of 122 matches
Mail list logo
