Simon Riggs wrote:
Personally, I want to see Jan contribute more, not less. The link with
Slony and related replication technology is critically important to
Postgres, which is why Jan has spent so long on it.
Generally we should be encouraging everybody to contribute; the project
must have a
> > > > > We allow /contrib to be more lax about beta changes.
> > > >
> > > > the postgresql ecosystem is growing and there is a lot of people like
> > > > packagers that will be a quite irritated if we keep randomly adding
> > > > completely new code and modules during BETA.
> > >
> > > Should
> > Simon Riggs wrote:
> >
> > > I would prefer that we backported pg_standby into 8.2 contrib, so the
> > > solution is where people need it to be. If not...
> > >
> > Don't know about the policy to put things in already-released-version
> > but if it's not the case, we could at least put the co
On Wed, 2007-10-10 at 01:14 -0300, Euler Taveira de Oliveira wrote:
> Simon Riggs wrote:
>
> > I would prefer that we backported pg_standby into 8.2 contrib, so the
> > solution is where people need it to be. If not...
> >
> Don't know about the policy to put things in already-released-version
>
On Tue, 2007-10-09 at 18:35 -0400, Andrew Dunstan wrote:
> I think this project has got too big for us to make things up as we go
> along. We need to follow processes that are well understood and
> transparent.
Well said, I very much agree.
Mostly we do, but since we've just spent more than 6
Ühel kenal päeval, K, 2007-10-10 kell 07:44, kirjutas Magnus Hagander:
> > > > We allow /contrib to be more lax about beta changes.
> > >
> > > the postgresql ecosystem is growing and there is a lot of people like
> > > packagers that will be a quite irritated if we keep randomly adding
> > > comp
Hi,
On Tue, 2007-10-09 at 17:10 -0700, Joshua D. Drake wrote:
> > (Will all respect to pginstaller team, I'm *think* it won't take
> much
> > time to add txid to installer, at least compared to the time that we
> > spent discussing this issue.)
>
> With respect, you don't know. My understanding o
> > > We allow /contrib to be more lax about beta changes.
> >
> > the postgresql ecosystem is growing and there is a lot of people like
> > packagers that will be a quite irritated if we keep randomly adding
> > completely new code and modules during BETA.
>
> Should packagers be concerned with
>
> OK, how do we even explain this idea in the FAQ. It pulls 20 random
> values from 1 to 1? That seems pretty hard to code to me. Where do
> you get the 1 number from? How do you know you will hit a match in
> 20 tries?
>
Number 1 you have to store in application .. it's magic co
Hi hackers,
I note that if you pass NULL to quote_literal(), you get NULL.
This isn't surprising, but I was thinking that the stated purpose of
quote_literal is preparing the argument for entry into a dynamic SQL
statement. In this context, it fails for NULL input.
Wouldn't it be more useful if
Simon Riggs wrote:
> I would prefer that we backported pg_standby into 8.2 contrib, so the
> solution is where people need it to be. If not...
>
Don't know about the policy to put things in already-released-version
but if it's not the case, we could at least put the code somewhere in
the ftp.post
Devrim GÜNDÜZ wrote:
Hi,
On Tue, 2007-10-09 at 16:50 -0700, Joshua D. Drake wrote:
IMO, the patch is reverted, and submitted for 8.4 or pgfoundry.
You know, txid was discussed in Slony-I + Skytools lists for a
reasonably long time, and Tom also commented in that thread. I agree
that we broke
Hi,
On Wed, 2007-10-10 at 06:25 +0300, Hannu Krosing wrote:
> Should packagers be concerned with /contrib at all ?
IMHO, yes. We (PGDG RPMs) ship contrib modules with a separate RPM, in
case someone wants to use it.
> Arguably, a good packager should make its own decisions about what to
> includ
On Wed, 10 Oct 2007 06:25:49 +0300
Hannu Krosing <[EMAIL PROTECTED]> wrote:
> As noted before /contrib is a technical way of ensuring that something
> gets updated together with core, not a recommendation to include it
> in a "package".
>
> Arguably, a good packager should make its own decisions
Simon Riggs escribió:
> OK, I've got this working now. It successfully handles this test case,
> which trips up on an auto ANALYZE every time I run it.
OK, nice, send your patch. I'm a bit disconnected these days so I'm not
sure when, but I'll commit mine shortly.
--
Alvaro Herrera
Ühel kenal päeval, T, 2007-10-09 kell 22:36, kirjutas Stefan
Kaltenbrunner:
> 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 w
Andrew Dunstan wrote:
>
>
> Devrim G?ND?Z wrote:
> > What we should to do is to prevent such things happening in the future,
> > rather than reverting this patch and delaying replication issues.
> >
> >
> >
>
> The next time the same sort of argument will be made. The way to prevent
> it in
Devrim GÜNDÜZ wrote:
What we should to do is to prevent such things happening in the future,
rather than reverting this patch and delaying replication issues.
The next time the same sort of argument will be made. The way to prevent
it in future is not to allow it now.
One of the thing
On Tue, 09 Oct 2007 17:07:29 -0700
Neil Conway <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-10-09 at 16:50 -0700, Joshua D. Drake wrote:
> > I think this almost says it all. My particular gripe about this
> > whole thing is that there are other features that are not too
> > intrusive (or appear so an
On Tue, 09 Oct 2007 17:04:41 -0700
Devrim GÜNDÜZ <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Tue, 2007-10-09 at 16:50 -0700, Joshua D. Drake wrote:
> > IMO, the patch is reverted, and submitted for 8.4 or pgfoundry.
>
> That means another delay for improving PostgreSQL replication.
No. It can go on
On Tue, 2007-10-09 at 16:50 -0700, Joshua D. Drake wrote:
> I think this almost says it all. My particular gripe about this whole
> thing is that there are other features that are not too intrusive (or
> appear so anyway) that are easily more useful that are not being
> considered at all. Namely,
Hi,
On Tue, 2007-10-09 at 16:50 -0700, Joshua D. Drake wrote:
> IMO, the patch is reverted, and submitted for 8.4 or pgfoundry.
That means another delay for improving PostgreSQL replication.
I think we are all pretty sure that Jan knows what he is doing -- he has
involved in replication issues f
On Tue, 9 Oct 2007 18:35:52 -0500
Michael Glaesemann <[EMAIL PROTECTED]> wrote:
>
> On Oct 9, 2007, at 0:06 , Bruce Momjian wrote:
>
> > I am surprised we are not backing
> > out the patch and requiring that the patch go through the formal
> > review
> > process.
>
> I have no opinion as to t
On Oct 9, 2007, at 0:06 , Bruce Momjian wrote:
I am surprised we are not backing
out the patch and requiring that the patch go through the formal
review
process.
I have no opinion as to the patch itself (other than the fact that
it's a not bug fix), but I think this patch should be rever
On Tue, Oct 09, 2007 at 01:06:11AM -0400, 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 o
Dave Page wrote:
> setlocale(LC_CTYPE, "English_United Kingdom.65001")
>
> will return null (and not change anything) because it doesn't like
> the combination of the locale and that encoding (UTF-8).
The reason that that call fails is probably that the operating system
does not provide such a lo
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
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
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 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
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
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,
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
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
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 *
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
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
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
> > >
> >
> > 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
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)---
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
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
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
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 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
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
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
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.
> >
>
>
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 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
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
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
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
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:
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
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
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
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.
> >>>
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
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,
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
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 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
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
"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
>>> 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
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, 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
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
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.
> > >
>
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
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.
>
>
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
[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.
[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
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
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".
>
>
"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
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
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, 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
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
>
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
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
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
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 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
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, 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
>>> 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 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
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
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
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
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
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
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 (
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
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
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
1 - 100 of 127 matches
Mail list logo
