At 2009-07-30 13:37:16 -0700, prent...@cisco.com wrote:
>
> This patch changes plpgsql IN parameters so they are mutable.
Makes sense, applies fine, works fine.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgres
>> That's what I want to believe. But picture if you have, say a
>> 1-terabyte table which is 50% dead tuples and you don't have a spare
>> 1-terabytes to rewrite the whole table.
>
>But trying to VACUUM FULL that table is going to be horridly painful
>too, and you'll still have bloated indexes aft
At 2009-09-16 01:18:10 -0500, jcasa...@systemguards.com.ec wrote:
>
> ok, maybe this is not the most brilliant observation but someone has
> to say it... keep the same case in the word "parameter" ;)
Oops, thanks. Re²vised patch attached.
-- ams
diff --git a/src/backend/utils/misc/guc-file.l b/sr
On Wed, Sep 16, 2009 at 12:24 AM, Abhijit Menon-Sen wrote:
>
> LOG: received SIGHUP, reloading configuration files
> LOG: parameter "log_connections" reset to default value "off"
> LOG: parameter "log_disconnections" reset to default value "off"
> LOG: Parameter "max_connections" cannot be cha
On Tue, 2009-07-21 at 20:54 +0300, Alexey Klyukin wrote:
> Attached is the updated version of the patch (the original description
> is here: http://archives.postgresql.org/pgsql-hackers/2009-07/msg01332.php)
> that doesn't use global variables. It also shows the last line of
> the context in
Itagaki Takahiro wrote:
> Hi,
>
> contrib/dblink doesn't transfar any non-error messages. Is it by design
> or to be a ToDo item? We can use PQsetNoticeReceiver() here.
I never thought about or needed, and no one else ever asked...patch
welcomed.
Joe
signature.asc
Description: OpenPGP digit
Itagaki Takahiro wrote:
> Stephen Frost wrote:
>
>> Can you provide an update on this patch? Joe, you were going to
>> review and possibly commit it. Itagaki, did you have a new version?
>> Are there any outstanding issues?
>
> Thanks for your reviewing.
> Here is an updated version. I f
On Tue, 2009-09-15 at 20:56 -0700, Jeff Janes wrote:
> Under what kind of circumstances/workload to you think this patch is
> most likely to show its full potential? I can try to test it out, but
> would like some guidance. I am guessing it is when the anti-wrap
> around vacuums come due, but tha
(This is my review of the small patch Peter posted on 2009-08-29. See
http://archives.postgresql.org/message-id/1251495487.18151.12.ca...@vanquo.pezone.net
for the original message.)
At 2009-08-29 00:38:07 +0300, pete...@gmx.net wrote:
>
> Found an easy solution; see attached patch.
Neat. The pat
Peter Eisentraut wrote:
> This patch is listed in the commitfest, but I think the consensus was
> that it needed some rework.
No doubt, but SQL/MED will require a lot of works. Can we split the work
into small parts? I intended FDW-based dblink to be one of the split jobs.
Here are some random
>From the patch review group this evening, courtesy of Webb Sprague and
Brent Dombrowski. I'm replying on their behalf so that this response
is in the correct thread.
Looks like Peter also reviewed, but I'm forwarding this on anyway.
(Note: Problem running regressions because make check doesn't
Stephen Frost wrote:
> Can you provide an update on this patch? Joe, you were going to
> review and possibly commit it. Itagaki, did you have a new version?
> Are there any outstanding issues?
Thanks for your reviewing.
Here is an updated version. I fixed some bugs:
* Fix connection
On Mon, Sep 14, 2009 at 2:07 AM, Jeff Davis wrote:
> On Mon, 2009-08-17 at 10:22 -0400, Tom Lane wrote:
> > As always with patches that are meant to improve performance,
> > some experimental evidence would be a good thing.
>
> I haven't had time to performance test this patch yet, and it looks l
Hi,
contrib/dblink doesn't transfar any non-error messages. Is it by design
or to be a ToDo item? We can use PQsetNoticeReceiver() here.
postgres=# SELECT * FROM dblink_exec('dbname=postgres', 'VACUUM VERBOSE');
No VERBOSE messages here
dblink_exec
-
VACUUM
(1 row)
Regar
Gah. rerolled to fix a missing file. includes the docs too this time.
--
Andrew (irc:RhodiumToad)
hstore-20090915.patch.gz
Description: hstore patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
On Tue, Sep 15, 2009 at 09:53:11PM -0400, Stephen Frost wrote:
> Michael,
>
> I just wanted to follow-up on your pgbench patch. The latest version
> that I see is from August 13th. Is that the correct patch to be
> reviewing? Do you have any other updates on it?
>
> Thanks!
>
>
2009/9/15 Pierre Frédéric Caillaud
> Does that heuristic change the timings much? If not, it seems like it
>> would
>> better to keep it simple and always do the same thing, like log the tuples
>> (if it is done under one WALInsertLock, which I am assuming it is..)
>>
>
> It is the logging of wh
On Tue, Sep 15, 2009 at 10:25 PM, Robert Haas wrote:
> On Tue, Sep 15, 2009 at 10:10 PM, Robert Haas wrote:
>>> * I'm not sure about this, because surely you would have tested it,
>>> but isn't it looking at the wrong side of the join clauses? I thought
>>> the idea is to prove the nullable (inn
Hi,
On Tue, Sep 15, 2009 at 7:53 PM, Heikki Linnakangas
wrote:
> After playing with this a little bit, I think we need logic in the slave
> to reconnect to the master if the connection is broken for some reason,
> or can't be established in the first place. At the moment, that is
> considered as
On Tue, Sep 15, 2009 at 10:10 PM, Robert Haas wrote:
>> * I'm not sure about this, because surely you would have tested it,
>> but isn't it looking at the wrong side of the join clauses? I thought
>> the idea is to prove the nullable (inner) side of the join unique.
>
> Grr. I think it's more br
On Tue, Sep 15, 2009 at 9:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> Here we go again. Following Tom's advice to not insert crocks in
>> add_path(), I've instead introduced a noopjoin path type which ignores
>> its inner side. This could possibly be simplified to just a "noop"
>> path that
Hi,
2009/9/16 Marc G. Fournier :
>
> Odd, I talked to him a couple of weeks ago and he was working on a new
> release in preparation for some upcoming talks he was doing ... was working
> on bringing it up to support 8.3.x ...
Yes. He will make a presentation about PGCluster at PGCon 2009 Japan.
Mark,
Your last email on this patch, from August 9th, indicates that you've
still got "TODO: redo pg_stat_lock_waits ...". Has you updated this
patch since then?
Thanks!
Stephen
signature.asc
Description: Digital signature
Michael,
I just wanted to follow-up on your pgbench patch. The latest version
that I see is from August 13th. Is that the correct patch to be
reviewing? Do you have any other updates on it?
Thanks!
Stephen
signature.asc
Description: Digital signature
Joe, Itagaki,
Can you provide an update on this patch? Joe, you were going to
review and possibly commit it. Itagaki, did you have a new version?
Are there any outstanding issues?
Thanks,
Stephen
signature.asc
Description: Digital signature
Robert Haas writes:
> Here we go again. Following Tom's advice to not insert crocks in
> add_path(), I've instead introduced a noopjoin path type which ignores
> its inner side. This could possibly be simplified to just a "noop"
> path that doesn't even include an outer side, but the way I've do
On Wed, Sep 16, 2009 at 2:23 AM, Kevin Grittner wrote:
> Scott Mohekey wrote:
> > I think the issue is that we treat TIMESTAMP WITHOUT TIME ZONE as
> > TIMESTAMP at GMT. We then convert it to a users local timezone
> > within application code.
>
> TIMESTAMP WITHOUT TIME ZONE is stored "raw" and
On Tue, Sep 15, 2009 at 05:52:35PM -0400, Tom Lane wrote:
> Jeff Davis writes:
> > On Tue, 2009-09-15 at 14:42 -0700, Jeff Davis wrote:
> >> operator constraints
> >> operator exclusion constraints
> >> operator conflict constraints
> >> conflict operator constraints
> >> operator index constraint
On Tue, Sep 15, 2009 at 10:41:59PM +0100, Simon Riggs wrote:
>
> OK, here is the latest version of the Hot Standby patchset. This is
> about version 30+ by now, but we should regard this as 0.2.1 Patch
> against CVS HEAD (now): clean apply, compile, no known bugs.
Kudos
Cheers,
David.
--
D
Jeff Davis writes:
> On Tue, 2009-09-15 at 14:42 -0700, Jeff Davis wrote:
>> operator constraints
>> operator exclusion constraints
>> operator conflict constraints
>> conflict operator constraints
>> operator index constraints
>> index constraints
>> generalized index constraints
>> something els
On Tue, 2009-09-15 at 14:42 -0700, Jeff Davis wrote:
> operator constraints
> operator exclusion constraints
> operator conflict constraints
> conflict operator constraints
> operator index constraints
> index constraints
> generalized index constraints
> something else?
Just to add a couple more
On Tue, 2009-09-15 at 12:49 -0700, David Fetter wrote:
> > I like this much better. Maybe "index operator constraints" or "operator
> > index constraints"?
>
> The word, "index" goes to implementation details, which may change.
Ok, let's vote on a name then:
operator constraints
operator exclusi
Perhaps you should post to the correct mailing list, which is
pgsql-j...@postgresql.org. Posting a real description of the position
- including where it's located, what the responsibilities are, and so
on, would be a good idea too.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Best Regards,
Ed Koch
Principal
Addison Search
212-378-1634
1350 Broadway NY,NY suite 810, 10018
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, dis
On Tue, 2009-09-15 at 16:58 -0400, Tom Lane wrote:
> Oh? Are you using 8.4+?
Oops, connecting to the wrong port. 8.5-dev works fine.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
Jeff Davis writes:
> S1, S2 are concurrent sessions:
> S1: create table test_par (v int);
> S1: create table test_ch1 (check (v > 0 and v <= 2)) inherits (test_par);
> S1: create table test_ch2 (check (v > 2 and v <= 4)) inherits (test_par);
> S1: begin;
> S1: drop table test_ch1 cascade;
> S2:
Since our shop seems to use domains more than most, I figured I
should comment on this thread.
>Sam Mason wrote:
>> On Tue, Sep 15, 2009 at 02:54:18PM +0100, Andrew Gierth wrote:
>> and the wording from 6.12 implies that that check is still
>> skipped in the case of NULLs (so that constraint wo
On Sep 15, 2009, at 11:01 AM, Andrew Gierth wrote:
If you want to store both a timestamp and an associated timezone you
can do
it right now, using a composite type or two columns, with the
advantage that
you get semantics that you can rely on.
How would a composite work in practice? Can yo
On Tue, Sep 15, 2009 at 12:22:46PM -0700, Jeff Davis wrote:
> On Tue, 2009-09-15 at 12:03 -0700, David Fetter wrote:
> > * "operator-based constraints"
> > A little math-ier, but talks about the API rather than details of
> > the server implementation.
>
> I like this much better. Maybe "i
Jeff Davis writes:
> On Tue, 2009-09-15 at 14:49 -0400, Tom Lane wrote:
>> Does it behave sanely for operators that are non-commutative, such
>> as '>'? (I'm not even very sure that I know what "sanely" would be
>> in such a case.)
> If you try it, my current patch won't stop you. Maybe I should
On Tue, 2009-09-15 at 12:03 -0700, David Fetter wrote:
> Interesting :) I take it op1..opN (it's opN, not op2, right?) need to
> commute?
Yeah, it's opN.
And they should commute, but my current patch won't stop you. I think I
should stop that though, it's pretty difficult to think of a good
use-
On Tue, 2009-09-15 at 14:49 -0400, Tom Lane wrote:
> Does it behave sanely for operators that are non-commutative, such
> as '>'? (I'm not even very sure that I know what "sanely" would be
> in such a case.)
One of the requirements is commutativity (I called it "symmetry" in the
docs, for some re
Andrew Gierth wrote:
> (To me, the fact that the spec's idea of 2009-01-31 + 1 month
> corresponds to a value that current_date will never be equal to is
> a far greater show-stopper.)
You get to pick which way you want to normalize that to the calendar
-- 31 days past the start of the next mo
On Tue, Sep 15, 2009 at 3:03 PM, David Fetter wrote:
> * "operator-based constraints"
> A little math-ier, but talks about the API rather than details of
> the server implementation.
Or operator-exclusion constraints? Operator-based exclusion constraints?
I'm feeling exclusive.
...Robert
S1, S2 are concurrent sessions:
S1: create table test_par (v int);
S1: create table test_ch1 (check (v > 0 and v <= 2)) inherits (test_par);
S1: create table test_ch2 (check (v > 2 and v <= 4)) inherits (test_par);
S1: begin;
S1: drop table test_ch1 cascade;
S2: select * from test_par where v =
On Tue, Sep 15, 2009 at 11:31:48AM -0700, Jeff Davis wrote:
> On Tue, 2009-09-15 at 13:48 -0400, Robert Haas wrote:
> > So it allows us to create constraints of the following form?
> >
> > For all A in the index, there exists no B in the index such that the
> > given operator (which must be a bina
Tom Lane wrote:
> [ shrug... ] We *have* that property, for sane cases such as
> adding and subtracting a fixed number of days.
Adding and subtracting months is very common in business software.
I have seen application bugs related to this many times. I suspect
that such bugs would occur les
Jeff Davis writes:
> On Tue, 2009-09-15 at 13:16 -0400, Robert Haas wrote:
>> Uhh so what happens if I create an index constraint using the
>> +(integer, integer) operator?
> You can use any operator that has an index search strategy. Overlaps is
> probably the most useful, but you could imag
On Tue, 2009-09-15 at 13:48 -0400, Robert Haas wrote:
> So it allows us to create constraints of the following form?
>
> For all A in the index, there exists no B in the index such that the
> given operator (which must be a binary operator returning boolean)
> holds of A and B.
Yes. And it's slig
Tom Lane wrote:
For less sane cases, I would point
out to Codd that the current calendar system was not designed by
mathematicians, and trying to superimpose strict mathematical rules on
it just leads to nonsense (like the spec's requirements).
He's not listening
Magnus Hagander wrote:
> I'm not sure I like this as a GUC. We're going to end up with a lot of
> different GUCs, and everytime we add a new log destination (admittedly
> not often, of course), that increases even further. And GUCs really
> don't provide the level of flexibility you'd really like
Accidentally left the doc patch out of the hstore patch posted
previously, so here it is as a separate patch.
--
Andrew (irc:RhodiumToad)
hstore-doc-20090914.patch.gz
Description: hstore doc patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
> "Kevin" == Kevin Grittner writes:
>> Given that the spec requires that 2009-01-31 + interval 1 month =
>> 2009-02-31 (yes, really! see general rule 4 in subsection 6.30), I
>> think we can safely ignore virtually everything it says about
>> date/time handling.
Kevin> Codd went on at
"Kevin Grittner" writes:
> Andrew Gierth wrote:
>> Given that the spec requires that 2009-01-31 + interval 1 month =
>> 2009-02-31 (yes, really! see general rule 4 in subsection 6.30), I
>> think we can safely ignore virtually everything it says about
>> date/time handling.
> Codd went on at so
On Tue, Sep 15, 2009 at 1:28 PM, Jeff Davis wrote:
> On Tue, 2009-09-15 at 13:16 -0400, Robert Haas wrote:
>> Uhh so what happens if I create an index constraint using the
>> +(integer, integer) operator?
>
> You can use any operator that has an index search strategy. Overlaps is
> probably th
On Tue, 2009-09-15 at 13:16 -0400, Robert Haas wrote:
> Uhh so what happens if I create an index constraint using the
> +(integer, integer) operator?
You can use any operator that has an index search strategy. Overlaps is
probably the most useful, but you could imagine other operators, like a
On Sep 15, 2009, at 10:17 AM, Tom Lane wrote:
try=# select extract(timezone_hour from '2001-02-16 20:38:40 America/
Los_Angeles'::timestamptz);
You appear to be confusing what PG currently does with what the spec
says.
Sorry, I thought you were referring to what PostgreSQL does. Would I
be
2009/9/16 Robert Haas :
> On Tue, Sep 15, 2009 at 1:14 PM, Brendan Jurd wrote:
>> 2009/9/16 Robert Haas :
>>> On Tue, Sep 15, 2009 at 12:54 PM, Jeff Davis wrote:
I don't want to call them "don't overlap constraints", because it's not
limited to a non-overlapping constraint.
>>>
>>> Oh.
std pik wrote:
> How can I get information about the hardware utilization:
This list is for discussing development of the PostgreSQL product.
Please re-post on the novice or admin list. You'll be more likely
to get a useful reply if you give people more information, like what
operating syst
"David E. Wheeler" writes:
> On Sep 15, 2009, at 8:50 AM, Tom Lane wrote:
>> See TIMEZONE_HOUR, TIMEZONE_MINUTE field specifications, in particular
> try=# select extract(timezone_hour from '2001-02-16 20:38:40 America/
> Los_Angeles'::timestamptz);
You appear to be confusing what PG currently
On Tue, Sep 15, 2009 at 1:14 PM, Brendan Jurd wrote:
> 2009/9/16 Robert Haas :
>> On Tue, Sep 15, 2009 at 12:54 PM, Jeff Davis wrote:
>>> I don't want to call them "don't overlap constraints", because it's not
>>> limited to a non-overlapping constraint.
>>
>> Oh. What else can you do with it?
>
Peter Eisentraut writes:
> On tis, 2009-09-15 at 11:32 -0400, Tom Lane wrote:
>> FWIW, I don't particularly agree with that --- there is no reason to
>> suppose that all PLs will want to do this exactly the same way.
> I'd imagine that we simply set the context to "$language function
> $name", pr
2009/9/16 Robert Haas :
> On Tue, Sep 15, 2009 at 12:54 PM, Jeff Davis wrote:
>> I don't want to call them "don't overlap constraints", because it's not
>> limited to a non-overlapping constraint.
>
> Oh. What else can you do with it?
Anything that there is an operator for.
Cheers,
BJ
--
Sent
On Tue, Sep 15, 2009 at 12:54 PM, Jeff Davis wrote:
> On Tue, 2009-09-15 at 12:37 -0400, Robert Haas wrote:
>> Instead of calling these generalized index constraints, I wonder if we
>> oughtn't to be calling them something like "don't-overlap constraints"
>> (that's a bad name, but something along
Peter Eisentraut wrote:
> The commitfest lists this as the last patch, but there was some
> discussion after this. Could you/we clarify what is actually
> proposed for inclusion now? I have seen proposals for:
>
> - Linux LSB init script
> - Linux non-LSB init script
> - SUSE specific init sc
On 9/15/09 2:34 AM, std pik wrote:
> Hello all..
> I'm using PostgreSQL 8.3..
> How can I get information about the hardware utilization:
>- CPU usage.
>- Disk space.
>- Memory allocation.
> thank you.
This is not a question for the -hackers mailing list. Please post your
On Tue, 2009-09-15 at 12:37 -0400, Robert Haas wrote:
> Instead of calling these generalized index constraints, I wonder if we
> oughtn't to be calling them something like "don't-overlap constraints"
> (that's a bad name, but something along those lines). They're not
> really general at all, excep
On tis, 2009-09-15 at 11:32 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > But for extra credit, couldn't we code it so that the context is set
> > before the PL handler is called, so that we get this functionality into
> > all PLs at once?
>
> FWIW, I don't particularly agree with that --
2009/9/16 Robert Haas :
> Instead of calling these generalized index constraints, I wonder if we
> oughtn't to be calling them something like "don't-overlap constraints"
> (that's a bad name, but something along those lines). They're not
> really general at all, except compared to uniqueness const
On Tue, Sep 15, 2009 at 5:34 AM, std pik wrote:
> Hello all..
> I'm using PostgreSQL 8.3..
> How can I get information about the hardware utilization:
> - CPU usage.
> - Disk space.
> - Memory allocation.
> thank you.
This question would be more appropriate for pgsql-general or
On Tue, Sep 15, 2009 at 12:18 PM, Jeff Davis wrote:
> On Tue, 2009-09-15 at 22:52 +1000, Brendan Jurd wrote:
>> I'm just getting started reviewing this version now. I noticed that
>> your patch seems to have been generated by git. Are you hosting this
>> work on a public repo somewhere that I ca
On Sep 15, 2009, at 8:50 AM, Tom Lane wrote:
See TIMEZONE_HOUR, TIMEZONE_MINUTE field specifications, in particular
b) Otherwise, let TZ be the interval value of the implicit
or explicit time zone associated with the expression>. If is TIMEZONE_HOUR, then
On Tue, 2009-09-15 at 08:08 -0600, Joshua Tolley wrote:
> Perhaps the tuple that caused the violation as well, like UNIQUE index
> violations already do? Even if we know what constraint has been tripped, we
> might not know what value did it.
Or, even better, include both tuples. With these new co
On Tue, 2009-09-15 at 23:21 +1000, Brendan Jurd wrote:
> How about also including the name of the constraint (or index) that
> was violated? I could imagine this error message being frustrating
> for someone who had a table with multiple index constraints, as they
> wouldn't know which one had rai
Odd, I talked to him a couple of weeks ago and he was working on a new
release in preparation for some upcoming talks he was doing ... was
working on bringing it up to support 8.3.x ...
"But, I'm just prepareing new version of the PGCluster..."
Mitani ... any status on this?
On Tue, 15 Sep
On Tue, 2009-09-15 at 13:16 -0300, Marc G. Fournier wrote:
> Odd, I talked to him a couple of weeks ago and he was working on a
> new
> release in preparation for some upcoming talks he was doing ... was
> working on bringing it up to support 8.3.x ...
>
> "But, I'm just prepareing new version o
On Tue, 2009-09-15 at 22:52 +1000, Brendan Jurd wrote:
> I'm just getting started reviewing this version now. I noticed that
> your patch seems to have been generated by git. Are you hosting this
> work on a public repo somewhere that I can pull from?
I just requested a public repo. I will publi
Andrew Gierth wrote:
>> ""Kevin" == "Kevin Grittner"
> writes:
>
> Kevin> TIMESTAMP WITH TIME ZONE is not completely ANSI-compliant,
>
> Given that the spec requires that 2009-01-31 + interval 1 month =
> 2009-02-31 (yes, really! see general rule 4 in subsection 6.30), I
> think we can saf
Hi,
I saw the editor added this line:
"Zoltan Boszormenyi sent in a small patch to fix a typo in an earlier
ECPG patch he sent."
This typo fix is an upstream bugfix.
Thanks.
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
th
Hello all..
I'm using PostgreSQL 8.3..
How can I get information about the hardware utilization:
- CPU usage.
- Disk space.
- Memory allocation.
thank you.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
David Fetter writes:
> On Tue, Sep 15, 2009 at 11:02:52AM -0400, Tom Lane wrote:
>> EXTRACT()?
> I see that EXTRACT() can take a time zone as input, but I don't see
> anywhere that could distinguish among the following inputs, once
> stored, as they have identical representations in UTC:
See TIM
On Tue, 2009-09-15 at 07:29 -0400, Marcos Luis Ortiz Valmaseda wrote:
> I was searching info about PgCluster-II yesterday and there is not
> much information about it.
> Do can give to me any report of this? Because I need to know the
> progress of the project.
It is dead.
--
Devrim GÜNDÜZ, RHCE
Peter Eisentraut writes:
> But for extra credit, couldn't we code it so that the context is set
> before the PL handler is called, so that we get this functionality into
> all PLs at once?
FWIW, I don't particularly agree with that --- there is no reason to
suppose that all PLs will want to do th
On Tue, Sep 15, 2009 at 11:02:52AM -0400, Tom Lane wrote:
> David Fetter writes:
> > I've looked through SQL:2008 (well, through
> > 6WD2_02_Foundation_2007-12.pdf), and I didn't find anything that
> > implies that the input time zone needs to be retrievable, nor
> > anything that would specify th
On Tue, Sep 15, 2009 at 7:48 AM, Marcos Luis Ortiz Valmaseda wrote:
> Yeah, the problem here is that CyberCluster is based yet on PostgreSQL 8.1
> and is a very old version to use it.
>
> I found the developer of PgCluster-II: Atsushi MITANI - mit...@sraw.co.jp
Yeah, AFAICS, PGCluster II is and
> ""Kevin" == "Kevin Grittner" writes:
Kevin> TIMESTAMP WITH TIME ZONE is not completely ANSI-compliant,
Given that the spec requires that 2009-01-31 + interval 1 month = 2009-02-31
(yes, really! see general rule 4 in subsection 6.30), I think we can safely
ignore virtually everything it sa
On Tue, 2009-07-21 at 20:54 +0300, Alexey Klyukin wrote:
> Attached is the updated version of the patch (the original description
> is here: http://archives.postgresql.org/pgsql-hackers/2009-07/msg01332.php)
> that doesn't use global variables.
Patch looks OK.
But for extra credit, couldn't
David Fetter writes:
> I've looked through SQL:2008 (well, through 6WD2_02_Foundation_2007-12.pdf),
> and I didn't find anything that implies that the input time zone needs
> to be retrievable, nor anything that would specify the syntax for
> doing so.
EXTRACT()?
regards,
On Tue, Sep 15, 2009 at 09:23:09AM -0500, Kevin Grittner wrote:
> Scott Mohekey wrote:
> > I think the issue is that we treat TIMESTAMP WITHOUT TIME ZONE as
> > TIMESTAMP at GMT. We then convert it to a users local timezone
> > within application code.
>
> That sounds like an accident waiting to
Scott Mohekey wrote:
> I think the issue is that we treat TIMESTAMP WITHOUT TIME ZONE as
> TIMESTAMP at GMT. We then convert it to a users local timezone
> within application code.
That sounds like an accident waiting to happen. Sure, you can make
it work, but you're doing things the hard way,
On Tue, Sep 15, 2009 at 02:54:18PM +0100, Andrew Gierth wrote:
> the spec _does_ appear to allow CHECK(VALUE IS NOT NULL) as a
> domain constraint (in general the spec defines NOT NULL constraints
> this way),
Huh, that's a trivial rewrite isn't it. Not sure why it didn't occur to
me that it's ju
On Tue, Sep 15, 2009 at 10:08 AM, Andrew Dunstan wrote:
> Brendan Jurd wrote:
>>
>> Perhaps we should move to something like:
>>
>> Accepting contributions => Under review => Complete.
> I say paint the bikeshed yellow!
>
> (h/t Dimitri)
-1. Yellow bikesheds are sometimes mistaken for giant
On Tue, Sep 15, 2009 at 11:21:14PM +1000, Brendan Jurd wrote:
> 2009/9/15 Jeff Davis :
> > Attached is the latest version.
> >
>
> The new error message for a conflict is:
>
> ERROR: index constraint violation detected
> DETAIL: tuple conflicts with existing data
>
> How about also including t
Brendan Jurd wrote:
Perhaps we should move to something like:
Accepting contributions => Under review => Complete.
I say paint the bikeshed yellow!
(h/t Dimitri)
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
Andrew Gierth writes:
> "Sam" == Sam Mason writes:
> Sam> The NOT NULL constraint feels wrong as well, what are the
> Sam> semantics of:
> Sam> CREATE DOMAIN d AS INTEGER NOT NULL;
> Sam> SELECT a.n AS aa, b.n AS bb
> Sam> FROM (VALUES (CAST(1 AS d)),(2)) a(n)
> Sam> LEFT JOIN (V
2009/9/15 Robert Haas :
> I believe the terminology we've been using, at least for the past year
> since I've been involved, is as follows:
>
> Open = open to new patches
> In Progress = working on reviewing and committing patches, no longer
> open to new patches
> Closed = all patches have been de
> "Sam" == Sam Mason writes:
>> But there's a kicker: in Subclause 6.12, , in the
>> General Rules is:
>>
>> a) If the specifies NULL, then the result of CS is
>> the null value and no further General Rules of this Subclause
>> are applied.
>>
>> That "no further General Rules" cla
On Tue, Sep 15, 2009 at 1:36 AM, Peter Eisentraut wrote:
> On mån, 2009-09-14 at 21:14 -0400, Robert Haas wrote:
>> [P.S. I learned my lesson - last CF the equivalent email said that the
>> CF was "closed", which of course was not what I meant at all.]
>
> Yeah, except is it just me or is this "op
On Wed, 2009-09-02 at 15:06 -0500, Kevin Grittner wrote:
> Wolfgang Wilhelm wrote:
>
> > if [ $# -lt 1 -o "$1" = "" ] ] ; then
>
> Oops. Fixed patch attached. Thanks!
The commitfest lists this as the last patch, but there was some
discussion after this. Could you/we clarify what is actua
2009/9/15 Jeff Davis :
> Attached is the latest version.
>
The new error message for a conflict is:
ERROR: index constraint violation detected
DETAIL: tuple conflicts with existing data
How about also including the name of the constraint (or index) that
was violated? I could imagine this erro
1 - 100 of 117 matches
Mail list logo
