Peter Eisentraut wrote:
> I think I could support using the presence of the BOM as a fall-back
> indicator of encoding in absence of any other declaration.
What is the difference the fall-back and <> ? I read this discussion that we cannot accept any automatic
encoding detections (properly spea
Hi,
Quoting "Greg Smith" :
"Synchronous replication - guarantees "zero data loss" by the means
of atomic write operation, i.e. write either completes on both sides
or not at all. Write is not considered complete until
acknowledgement by both local and remote storage."
Note that a storage
Itagaki-san, I checked the latest patch.
It seems to me the patch getting improved from the prior version.
We are next to the commiter review phase.
But I could find a few matters. :-(
Please see the following comments, and fix it before sending it
to commiters.
> I fixed the bug and two other b
On tis, 2009-11-17 at 14:19 +0900, Itagaki Takahiro wrote:
> The attachd patch is a new proposal of the feature.
> When we found BOM at beginning of file, set "expected_encoding" to UTF8.
> Before every execusion of query, if pset.encoding is not UTF8, we check the
> query string not to contain any
On mån, 2009-11-16 at 20:30 -0700, Alex Hunsaker wrote:
> While looking over the writable cte patch I noticed queries.sgml has
> lots of things in the form "FROM". I tried various
> googles to see if is some kind of sgml/xml shorthand for close the
> last opened tag. But alas, nothing found. Ba
On Sun, Nov 15, 2009 at 14:27, Marko Tiikkaja
wrote:
> I wrote:
>>
>> Attached is the latest version of this patch.
Find attached a incremental diff with the following changes:
-get rid of operation argument to InitResultRelInfo, its unused now
-add some asserts to make sure places we use subplan
On Sun, Nov 15, 2009 at 1:43 PM, Andrew Dunstan wrote:
>
>
> George Gensure wrote:
>>
>> This begs a bigger question: what's *really* easy or low barrier to
>> entry for very light contributors like myself? - I've got time, I like
>> the product, I need to know what's going to get you a win, I ma
Tom Lane wrote:
> Itagaki Takahiro writes:
> > If encoding setting is reverted,
> >> "Eat BOM at beginning of file and <>"
> > will be much safer.
>
> This isn't going to happen, so please stop wasting our time arguing
> about it.
Ok, sorry. But I still cannot accept this restriction.
>> - O
On Mon, Nov 16, 2009 at 10:54 PM, Alex Hunsaker wrote:
> On Mon, Nov 16, 2009 at 20:41, Tom Lane wrote:
>> Apparently --- it's perfectly legal in SGML. (I think not in XML.)
>
> Cool. Thanks!
>
> BTW anyone know how to escape < and > for google? I tried searching
> for it-- but ran into a chick
On Mon, Nov 16, 2009 at 10:42 PM, Tom Lane wrote:
> "Greg Sabino Mullane" writes:
>> Is there any chance we can raise the default geqo_threshold from
>> its current default of 12?
>
> We were over that just a few months ago.
Yeah. I think we need to see if we can do something about the
ridiculo
On Mon, Nov 16, 2009 at 20:41, Tom Lane wrote:
> Apparently --- it's perfectly legal in SGML. (I think not in XML.)
Cool. Thanks!
BTW anyone know how to escape < and > for google? I tried searching
for it-- but ran into a chick and egg situation. So the I tried
various forms of "google search
Itagaki Takahiro writes:
> If encoding setting is reverted,
>> "Eat BOM at beginning of file and <>"
> will be much safer.
This isn't going to happen, so please stop wasting our time arguing
about it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hack
Tom Lane wrote:
Alex Hunsaker writes:
While looking over the writable cte patch I noticed queries.sgml has
lots of things in the form "FROM". I tried various
googles to see if is some kind of sgml/xml shorthand for close the
last opened tag. But alas, nothing found. Bad google foo?
"Greg Sabino Mullane" writes:
> Is there any chance we can raise the default geqo_threshold from
> its current default of 12?
We were over that just a few months ago.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Alex Hunsaker writes:
> While looking over the writable cte patch I noticed queries.sgml has
> lots of things in the form "FROM". I tried various
> googles to see if is some kind of sgml/xml shorthand for close the
> last opened tag. But alas, nothing found. Bad google foo?
Apparently --- it'
While looking over the writable cte patch I noticed queries.sgml has
lots of things in the form "FROM". I tried various
googles to see if is some kind of sgml/xml shorthand for close the
last opened tag. But alas, nothing found. Bad google foo?
Should we change those to be the right closing ta
KaiGai Kohei wrote:
> Itagaki-san, I also think your example usage is enough valueable.
> However, Oracle does not have the feature apparently, although the
> purpose of this patch is to provide a compatible feature, IIRC.
>
> I don't have any preference on either of them.
> If you make a decis
Tom Lane wrote:
> Andrew Dunstan writes:
> > if you need to, using PGOPTIONS or psql
> > "dbname=mydb options='-c client_encoding=utf8'".
>
> It could also be set in ~/.psqlrc, which would probably be the most
> convenient method for regular users of UTF8 files who need to talk
> to non-UTF8
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> old method scaled (badly) on volume of notifications and your stuff
> seems to scale based on # of client's sending simultaneous
> notifications. Well, you're better all day long, but it shows that
> your fears regarding locking were not com
Tom Lane wrote:
A good rule of thumb is to never do code development in a non-cassert
build.
And the same rule goes for review, too; I'll update the review
guidelines to spell that out more clearly. Basically, if you're doing
any work on new code, you should have cassert turned on, *except* i
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Is there any chance we can raise the default geqo_threshold from
its current default of 12? This seems too low, as a modern Postgres
on modern hardware has no problem with 12 table joins. However, I have
seen geqo causing trouble for clients whe
On Mon, Nov 16, 2009 at 6:56 PM, Tom Lane wrote:
> Brendan Jurd writes:
>> One of the rewards for getting a patch into the tree is having your
>> name immortalised in the commit log. There's no such compensation for
>> reviewing patches.
>
> Well, that could be fixed: instead of
>
> blah
On Nov 16, 2009, at 8:47 PM, "Joshua D. Drake"
wrote:
On Mon, 2009-11-16 at 19:15 -0500, Andrew Dunstan wrote:
Brendan Jurd wrote:
One of the rewards for getting a patch into the tree is having your
name immortalised in the commit log. There's no such compensation
for
reviewing patches
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> Program received signal SIGSEGV, Segmentation fault.
> 0x0819368b in route_tuple_to_child (parent_relation=0xb5d93040,
> tuple=0x873b08c, hi_options=0, parentResultRelInfo=0x871e204) at copy.c:1821
> 1821child_relation_id =
> c
On Mon, 2009-11-16 at 19:15 -0500, Andrew Dunstan wrote:
>
> Brendan Jurd wrote:
> > One of the rewards for getting a patch into the tree is having your
> > name immortalised in the commit log. There's no such compensation for
> > reviewing patches.
> >
> > I think creating incentives to review i
Andrew Dunstan writes:
> As for when it can be set, unless I'm mistaken you should be able to set
> it before any file is opened, if you need to, using PGOPTIONS or psql
> "dbname=mydb options='-c client_encoding=utf8'". Of course, if the
> server encoding is utf8 then, in the absence of it bei
Itagaki Takahiro wrote:
Peter Eisentraut wrote:
OK, I think the consensus here is:
- Eat BOM at beginning of file (as you implemented)
- Only when client encoding is UTF-8 --> please fix that
Are they AND condition? If so, this patch will be useless.
Please remember \encoding or SE
Itagaki Takahiro writes:
> Please remember \encoding or SET client_encoding appear
> *after* BOM at beginning of file. I'll agree if the condition is
> "Eat BOM at beginning of file and <>",
As has been stated multiple times, that will not get accepted,
because it will *break* files in other enc
Hi,
I'll hopefully look at the next version of the patch tommorrow.
Emmanuel Cecchet wrote:
>> o test1.sql always segfaults for me, poking around with gdb suggests
>> it's a case of an uninitialised cache list (another reason to use the
>> builtin one).
>>
> I was never able to reproduce that
Peter Eisentraut wrote:
> OK, I think the consensus here is:
> - Eat BOM at beginning of file (as you implemented)
> - Only when client encoding is UTF-8 --> please fix that
Are they AND condition? If so, this patch will be useless.
Please remember \encoding or SET client_encoding appear
*after
> > Please correct me if I'm wrong. Parse will result in obtaining
> > RowExclusiveLock on the target table if it is parsing
> > INSERT/UPDATE/DELETE. If so, is this ok in the standby?
>
> Any attempt to take RowExclusiveLock will fail.
>
> Any attempt to execute INSERT/UPDATE/DELETE will fail.
>
Brendan Jurd wrote:
One of the rewards for getting a patch into the tree is having your
name immortalised in the commit log. There's no such compensation for
reviewing patches.
I think creating incentives to review is going to be more potent and
more enjoyable for everyone involved than punit
Brendan Jurd writes:
> One of the rewards for getting a patch into the tree is having your
> name immortalised in the commit log. There's no such compensation for
> reviewing patches.
Well, that could be fixed: instead of
blah blah blah
Joe Coder
we could write
blah b
2009/11/17 David Fetter :
> In the PostgreSQL Weekly News, I track patches, and apparently at
> least one person reads that section. Would it be helpful to track
> reviews somehow during commitfests with the reviewers' names
> prominently attached?
>
Yes. See also my suggestion [1] that we do a
On Mon, Nov 16, 2009 at 12:41:02PM -0500, Chris Browne wrote:
> j...@commandprompt.com ("Joshua D. Drake") writes:
> > On Mon, 2009-11-16 at 11:31 -0500, Chris Browne wrote:
> >
> >> Ah, but the thing is, what was proposed wasn't "totally evilly
> >> draconian."
> >>
> >> There's a difference betw
On Sun, Nov 15, 2009 at 12:10:33PM +1100, Brendan Jurd wrote:
> I noticed that there was a fairly large amount of bogus/inconsistent
> whitespace in the patch, particularly in the body of
> plperl_inline_handler(). Some of the lines were indented with tabs,
> others with spaces. You should stick
--On 16. November 2009 11:00:33 -0700 Alex Hunsaker
wrote:
Anyway Bernd if you are working on this great! If not lemme know, Ill
plan on having something for the next commit feast. Though I still
may never get around to it :(.
I'm just working on it.
The current patch assigns __not_nul
Hello
now - complete patch
ToDo:
* enhance a documentation (any volunteer?)
* check name for backslash command
Regards
Pavel Stehule
*** ./doc/src/sgml/ref/psql-ref.sgml.orig 2009-10-13 23:04:01.0 +0200
--- ./doc/src/sgml/ref/psql-ref.sgml 2009-11-16 22:44:50.530277356 +0100
On Mon, Nov 16, 2009 at 4:41 PM, Joachim Wieland wrote:
> On Sat, Nov 14, 2009 at 11:06 PM, Merlin Moncure wrote:
>> The old method (measured on a 4 core high performance server) has
>> severe scaling issues due to table bloat (we knew that):
>> ./pgbench -c 10 -t 1000 -n -b listen.sql -f notify.
On Sat, Nov 14, 2009 at 11:06 PM, Merlin Moncure wrote:
> The old method (measured on a 4 core high performance server) has
> severe scaling issues due to table bloat (we knew that):
> ./pgbench -c 10 -t 1000 -n -b listen.sql -f notify.sql
> run #1 tps = 1364.948079 (including connections establis
Jeff Davis writes:
> On Mon, 2009-11-16 at 13:37 +0900, Itagaki Takahiro wrote:
>> [ new options syntax for VACUUM ]
> Great, I am marking this part "ready for committer".
Applied with very minor editorialization.
regards, tom lane
--
Sent via pgsql-hackers mailing lis
On Mon, Nov 16, 2009 at 11:45, Tom Lane wrote:
> Alex Hunsaker writes:
>> FYI defaults have the same problem. Would it be awkward would it be
>> to use pg_constraint for the book keeping as well? [ and by that I
>> really mean ALTER TABLE ADD CONSTRAINT my_default DEFAULT so you
>> can giv
Peter Eisentraut writes:
> I'm not sure if replacing a BOM by three spaces is a good way to
> implement "eating", because it might throw off a column indicator
> somewhere, say, but I couldn't reproduce a problem. Note that the U
> +FEFF character is defined as *zero-width* non-breaking space.
S
SebiF wrote:
> Hi Everyone,
>
> Given a table "Items" with a PK "item1" and "Qty" - a numeric column
> I'd like to define a way in Postgres to insert when item11 doesn't
> exist already in "Items" and update the Qty by adding the new quantity
> to the existent when the item11 exists. What is a go
Markus Wanner wrote:
You will definitely find different definitions and requirements of what
synchronous replication means there.
To quote from the Wikipedia entry on "Database Replication" that Simon
pointed to during the earlier discussion,
http://en.wikipedia.org/wiki/Database_replication
On ons, 2009-10-21 at 13:11 +0900, Itagaki Takahiro wrote:
> Sure. Client encoding is declared in body of a file, but BOM is
> in head of the file. So, we should always ignore BOM sequence
> at the file head no matter what client encoding is used.
>
> The attached patch replace BOM with while spac
On Wednesday 11 November 2009 18:50:46 Sergey Konoplev wrote:
> Hello community,
>
>
> Second time after migration 8.3.7 --> 8.4.1 I was caught by this
> problem. Migration was 8 days ago.
> (note, I never seen such situation on 8.3)
Is 8.4 configured similarly to 8.3?
Andres
--
Sent via pgsql
> "Tom" == Tom Lane writes:
Tom> Ron Mayer writes:
>> [1] http://archives.postgresql.org/pgsql-general/2006-11/msg01544.php
Tom> FWIW, the behavior has changed from the time of that discussion ---
Tom> we now track sort ordering using EquivalenceClasses, which are able
Tom> to distingu
On Mon, Nov 16, 2009 at 1:31 PM, SebiF wrote:
> Hi Everyone,
>
> Given a table "Items" with a PK "item1" and "Qty" - a numeric column
> I'd like to define a way in Postgres to insert when item11 doesn't
> exist already in "Items" and update the Qty by adding the new quantity
> to the existent when
On Mon, Nov 16, 2009 at 1:53 PM, Sergey Konoplev wrote:
> On Thu, Nov 12, 2009 at 4:42 AM, Robert Haas wrote:
>> On Wed, Nov 11, 2009 at 12:50 PM, Sergey Konoplev wrote:
>>> Was this situation mentioned before and is there a solution or
>>> workaround? (I didn't find any) If not please give me a
Sergey Konoplev escribió:
> I tried to get locks with this queries
Did you try pg_locks?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On Thu, Nov 12, 2009 at 4:42 AM, Robert Haas wrote:
> On Wed, Nov 11, 2009 at 12:50 PM, Sergey Konoplev wrote:
>> Was this situation mentioned before and is there a solution or
>> workaround? (I didn't find any) If not please give me a glue where to
>> dig or what information should I provide?
>
Hi Everyone,
Given a table "Items" with a PK "item1" and "Qty" - a numeric column
I'd like to define a way in Postgres to insert when item11 doesn't
exist already in "Items" and update the Qty by adding the new quantity
to the existent when the item11 exists. What is a good approach and
where shou
Alex Hunsaker writes:
> FYI defaults have the same problem. Would it be awkward would it be
> to use pg_constraint for the book keeping as well? [ and by that I
> really mean ALTER TABLE ADD CONSTRAINT my_default DEFAULT so you
> can give them a name ]
That sounds moderately insane to me.
Ron Mayer writes:
> [1] http://archives.postgresql.org/pgsql-general/2006-11/msg01544.php
FWIW, the behavior has changed from the time of that discussion ---
we now track sort ordering using EquivalenceClasses, which are able
to distinguish different instances of textually equal() volatile
expres
On Mon, Nov 16, 2009 at 1:08 PM, Joshua D. Drake wrote:
>> True. But "not enough reviewers to review all the patches we get" is
>> also a barrier to contribution.
>
> No. It is a barrier of contribution not to contribution.
I am not sure exactly what that means, but I agree that it isn't quite
t
Hi,
Greg Stark wrote:
I think my definition would be that a query against the replica will
produce the same result as a query against the master -- and that that
will be the case even after a system failure. That might not
necessarily mean that the log entry is fsynced on the replica, only
that
On Mon, 2009-11-16 at 12:42 -0500, Robert Haas wrote:
> On Mon, Nov 16, 2009 at 12:17 PM, Joshua D. Drake
> wrote:
> > On Mon, 2009-11-16 at 11:31 -0500, Chris Browne wrote:
> >
> >> Ah, but the thing is, what was proposed wasn't "totally evilly
> >> draconian."
> >>
> >> There's a difference bet
j...@commandprompt.com ("Joshua D. Drake") writes:
> On Mon, 2009-11-16 at 11:31 -0500, Chris Browne wrote:
>
>> Ah, but the thing is, what was proposed wasn't "totally evilly
>> draconian."
>>
>> There's a difference between:
>>
>> "You haven't reviewed any patches - we'll ignore you forever!"
On Thu, Nov 12, 2009 at 11:56, Bernd Helmle wrote:
> I've just started looking into this and wonder how this should look like.
IIRC another motivation for moving them into pg_constraint was we
could then give them names as required by the spec (unless I got mixed
up with defaults). Looking at th
Andrew Gierth writes:
> If you try it using nextval(), you'll notice that the function does
> in fact get called twice per row, but one of the results is thrown
> away and replaced with the other one.
Yeah. The problem is that setrefs.c is generating a tlist for the
hashagg node in which both ou
> "Tom" == Tom Lane writes:
>> For bonus weirdness:
>> select distinct random(),random() from generate_series(1,10);
>> set enable_hashagg=off;
>> select distinct random(),random() from generate_series(1,10);
>> I think _that_ one is a bug.
Tom> Hmm. I think the first one is a bug -
On Mon, Nov 16, 2009 at 12:17 PM, Joshua D. Drake
wrote:
> On Mon, 2009-11-16 at 11:31 -0500, Chris Browne wrote:
>
>> Ah, but the thing is, what was proposed wasn't "totally evilly
>> draconian."
>>
>> There's a difference between:
>>
>> "You haven't reviewed any patches - we'll ignore you fore
On Mon, 2009-11-16 at 11:31 -0500, Chris Browne wrote:
> Ah, but the thing is, what was proposed wasn't "totally evilly
> draconian."
>
> There's a difference between:
>
> "You haven't reviewed any patches - we'll ignore you forever!"
>
> and
>
> "Since you haven't reviewed any patches, we a
On Mon, 2009-11-16 at 19:06 +0900, Tatsuo Ishii wrote:
> > > - Does Hot Standby allow to use prepared query (not prepared
> > > transaction) in standby? I mean: Parse message from frontend can be
> > > accepted by standby?
> >
> > Yes, no problem with any of those kind of facilities
>
> Pleas
On mån, 2009-11-16 at 10:05 -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > Magnus Hagander wrote:
> >> On Mon, Nov 16, 2009 at 08:29, David Fetter wrote:
> >>> On Mon, Nov 16, 2009 at 06:56:54AM +0200, Peter Eisentraut wrote:
> Yeah, sorry guys. I fixed the CVS log message now.
>
and...@dunslane.net (Andrew Dunstan) writes:
> Robert Haas wrote:
>> I am personally quite tired of reviewing patches for people who don't
>> in turn review mine (or someone's). It makes me feel like not
>> working on this project. If we can solve that problem without
>> implementing a policy of
Boszormenyi Zoltan wrote:
> Hi,
>
> I am using this code on 8.4/8.5, which works on 64-bit,
> but segfaults on 32-bit Linux:
>
I'm not sure but perhaps this patch could help you. It may be a bit outdated.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQ
On Mon, Nov 16, 2009 at 11:07 AM, Kevin Grittner
wrote:
> Tom Lane wrote:
>
>> I agree with Heikki that it would be better not to commit as long as
>> any clear showstoppers remain unresolved.
>
> I agree that it would be better not to commit as long as any of the
> following are true:
>
> (1) T
Tom Lane wrote:
> I agree with Heikki that it would be better not to commit as long as
> any clear showstoppers remain unresolved.
I agree that it would be better not to commit as long as any of the
following are true:
(1) There are any known issues which would break things for clusters
2009/11/16 Tom Lane :
> Pavel Stehule writes:
>> 2009/11/16 Tom Lane :
>>> What timezone setting are you using? I'd bet a great deal that
>>> +00:57:44 is what the Olsen database shows as the LMT offset for
>>> your zone before standardized timezones were adopted.
>
>> I am using CET.
>
> "CET" c
Pavel Stehule writes:
> 2009/11/16 Tom Lane :
>> What timezone setting are you using? Â I'd bet a great deal that
>> +00:57:44 is what the Olsen database shows as the LMT offset for
>> your zone before standardized timezones were adopted.
> I am using CET.
"CET" covers a multitude of sins, but I
2009/11/16 Tom Lane :
> Pavel Stehule writes:
>> It looks like to_timestamp returns some strange timezone value
>
> What timezone setting are you using? I'd bet a great deal that
> +00:57:44 is what the Olsen database shows as the LMT offset for
> your zone before standardized timezones were adop
Pavel Stehule writes:
> It looks like to_timestamp returns some strange timezone value
What timezone setting are you using? I'd bet a great deal that
+00:57:44 is what the Olsen database shows as the LMT offset for
your zone before standardized timezones were adopted.
re
Heikki Linnakangas writes:
> Magnus Hagander wrote:
>> On Mon, Nov 16, 2009 at 08:29, David Fetter wrote:
>>> On Mon, Nov 16, 2009 at 06:56:54AM +0200, Peter Eisentraut wrote:
Yeah, sorry guys. I fixed the CVS log message now.
>> So it's not only not strange, I'm very happy it didn't pull
Andrew Gierth writes:
> For bonus weirdness:
> select distinct random(),random() from generate_series(1,10);
> set enable_hashagg=off;
> select distinct random(),random() from generate_series(1,10);
> I think _that_ one is a bug.
Hmm. I think the first one is a bug --- the two invocations of
r
Hello
our customer reports different result of to_timestamp function between
8.3 and 8.4
It looks like to_timestamp returns some strange timezone value
postgres=# select to_timestamp('00:00:00','HH24:MI:SS');
to_timestamp
─
0001-01-01 00:00:00+00:57:44
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
We still need to decide what to do with queue full situations in
the proposed listen/notify implementation. I have a new ve
On Mon, Nov 16, 2009 at 4:30 AM, Magnus Hagander wrote:
> On Mon, Nov 16, 2009 at 10:20, Heikki Linnakangas
> wrote:
>> Magnus Hagander wrote:
>>> On Mon, Nov 16, 2009 at 02:08, Bruce Momjian wrote:
Magnus Hagander wrote:
> On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote:
>> On Sa
On Mon, Nov 16, 2009 at 4:37 AM, Bernd Helmle wrote:
> --On 14. November 2009 20:22:42 -0500 Robert Haas
> wrote:
>
>> I will take another crack at it.
>>
>> ...Robert
>
> I take this that you are going to provide a new patch version?
Yes. I'm not sure whether or not it will be in time for this
On Mon, Nov 16, 2009 at 9:05 AM, Greg Sabino Mullane >> We still need
to decide what to do with queue full situations in
>> the proposed listen/notify implementation. I have a new version
>> of the patch to allow for a variable payload size. However, the
>> whole notification must fit into one page
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> You misunderstand the requirements. LISTEN notifications are *not*
>> meant to survive a database crash, and never have been. However,
>> so long as both client and server stay up, they must be reliable.
>> If the client has to poll databas
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> We still need to decide what to do with queue full situations in
> the proposed listen/notify implementation. I have a new version
> of the patch t
Dear PostgreSQL developers,
We are researching the motivation factors of Open Source software
programmers and would like to ask your cooperation in our large-scale
research. The research is performed for the Amsterdam Business School of
the University of Amsterdam. Your participation would con
Andrew Gierth wrote:
> This query:
>
> select random() from generate_series(1,10) order by random();
> produces sorted output. Should it?
I recall a workaround from a different thread[1] if specifically
were looking for random ordering of random numbers is:
select random() from foo order
On sön, 2009-11-15 at 12:37 -0500, Andrew Dunstan wrote:
> At Tom's suggestion I am looking at allowing use of parameter names in
> SQL functions instead of requiring use of $1 etc. That raises the
> question of how we would disambiguate a parameter name from a column
> name. Essentially, ISTM,
Albe Laurenz wrote:
> SQL> CREATE TRIGGER dummy BEFORE DELETE ON employees WHEN (1 = 1)
> 2 BEGIN
> 3 END;
> 4 /
> CREATE TRIGGER dummy BEFORE DELETE ON employees WHEN (1 = 1)
> *
> ERROR at line 1:
> ORA-04077: WHEN clause cannot be used wit
KaiGai Kohei wrote:
> I'm uncertain how Oracle handles the condition on the statement
> triggers. But it seems to me WHEN clause on the statement triggers
> are nonsense.
SQL> CREATE TRIGGER dummy BEFORE DELETE ON employees WHEN (1 = 1)
2 BEGIN
3 END;
4 /
CREATE TRIGGER dummy BEFORE DELET
> > - Does Hot Standby allow to use prepared query (not prepared
> > transaction) in standby? I mean: Parse message from frontend can be
> > accepted by standby?
>
> Yes, no problem with any of those kind of facilities
Please correct me if I'm wrong. Parse will result in obtaining
RowExclusiv
--On 14. November 2009 20:22:42 -0500 Robert Haas
wrote:
I will take another crack at it.
...Robert
I take this that you are going to provide a new patch version?
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
On Mon, Nov 16, 2009 at 10:20, Heikki Linnakangas
wrote:
> Magnus Hagander wrote:
>> On Mon, Nov 16, 2009 at 02:08, Bruce Momjian wrote:
>>> Magnus Hagander wrote:
On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote:
> On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander
> wrote:
>>
Here is an updated patch of rewriting vacuum based on vacuum options patch.
Documentations and vacuumdb modification (-i, --inplace) are added.
Jeff Davis wrote:
> 1. Do we want to introduce syntax for INPLACE at all, if we are
> eventually going to remove the current mechanism?
> My opinion is
Magnus Hagander wrote:
> On Mon, Nov 16, 2009 at 02:08, Bruce Momjian wrote:
>> Magnus Hagander wrote:
>>> On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote:
On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander
wrote:
> How about we add specific feature(s) about tihs to the commitfest
Heikki Linnakangas wrote:
> So we could rewrite the git history too, and I think it would be quite
> nice to have the right commit message there as well. But I don't care
> enough to volunteer to do the legwork. If we are going to do it, we
> should do it as soon as possible, while we're only a cou
On Mon, Nov 16, 2009 at 09:05, Heikki Linnakangas
wrote:
> Magnus Hagander wrote:
>> On Mon, Nov 16, 2009 at 08:29, David Fetter wrote:
>>> On Mon, Nov 16, 2009 at 06:56:54AM +0200, Peter Eisentraut wrote:
Yeah, sorry guys. I fixed the CVS log message now.
>>> Strangely, the git repo still
2009/11/16 Itagaki Takahiro :
>
> Pavel Stehule wrote:
>
>> I propose to add possibility to use psql variables as real query
>> parameters. The goal of this proposal is simplification of creating
>> psql based commands.
>
>> postgres=# \pexec
>> Separately passing parameters is on.
>> postgres=# s
Magnus Hagander wrote:
> On Mon, Nov 16, 2009 at 08:29, David Fetter wrote:
>> On Mon, Nov 16, 2009 at 06:56:54AM +0200, Peter Eisentraut wrote:
>>> Yeah, sorry guys. I fixed the CVS log message now.
>> Strangely, the git repo still shows the old message. For the record,
>> there's the new one:
On Mon, Nov 16, 2009 at 02:32, Robert Haas wrote:
> On Sun, Nov 15, 2009 at 8:08 PM, Bruce Momjian wrote:
>> Magnus Hagander wrote:
>>> On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote:
>>> > On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander
>>> > wrote:
>>> >> How about we add specific feature
On Mon, Nov 16, 2009 at 02:08, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote:
>> > On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander
>> > wrote:
>> >> How about we add specific feature(s) about tihs to the commitfest
>> >> management tool? Like
On Mon, 2009-11-16 at 13:23 +0900, Tatsuo Ishii wrote:
> Just a question:
>
> - Does Hot Standby allow to use prepared query (not prepared
> transaction) in standby? I mean: Parse message from frontend can be
> accepted by standby?
Yes, no problem with any of those kind of facilities
> - Can
100 matches
Mail list logo
