On Mon, 25 Oct 2010 21:45:23 -0400
Robert Haas wrote:
> On Mon, Oct 25, 2010 at 8:51 AM, KaiGai Kohei wrote:
> > One possible candidate is CheckMyDatabase() that checks ACL_CONNECT
> > permission for the required database prior to execution of all the
> > queries.
> > Currently, we don't have an
On Tue, Oct 26, 2010 at 12:28 AM, Tom Lane wrote:
> But it might be a good change anyway from a performance standpoint,
> in case a call through a function pointer is faster than a big switch.
> Have you tried benchmarking it on common platforms?
I didn't intend performance, but there is small bu
On Tue, Oct 26, 2010 at 11:34 AM, David Fetter wrote:
>> Do we need to 'add' it?
> Possibly. My understanding is that it couldn't really replace it.
Ah, I see. I was wrong. We can have modification privileges for views
even if they have no INSTEAD OF triggers.
So, I think your original patch is
On Tue, Oct 26, 2010 at 11:10:53AM +0900, Itagaki Takahiro wrote:
> On Tue, Oct 26, 2010 at 10:53 AM, David Fetter wrote:
> >> How about has_table_privilege() to filter candidate relations
> >
> > That's orthogonal to tgtype (snip) Shall I send a new patch with
> > that added?
>
> Do we need to '
On Tue, Oct 26, 2010 at 10:53 AM, David Fetter wrote:
>> How about has_table_privilege() to filter candidate relations
>
> That's orthogonal to tgtype (snip)
> Shall I send a new patch with that added?
Do we need to 'add' it? I intended to replace the JOIN with pg_trigger
to has_table_privilege()
On Tue, Oct 26, 2010 at 10:30:49AM +0900, Itagaki Takahiro wrote:
> On Tue, Oct 26, 2010 at 5:01 AM, David Fetter wrote:
> > Please find attached patch for $subject :)
>
> Thank you for maintaining psql tab completion, but I'm not sure
> whether tgtype is the best column for the purpose. How abo
On Mon, Oct 25, 2010 at 8:51 AM, KaiGai Kohei wrote:
> One possible candidate is CheckMyDatabase() that checks ACL_CONNECT
> permission for the required database prior to execution of all the
> queries.
> Currently, we don't have any security hook around here.
> But, if we have "InvokeSecurityHook
On 10/25/2010 07:12 PM, Tom Lane wrote:
However, that objection doesn't hold for plperl or pltcl (and likely
not plpython, though I don't know that language enough to be sure).
So it would be a reasonable feature request to teach those PLs to
accept "record" parameters. I think the fact that t
On Fri, Oct 22, 2010 at 3:08 PM, fazool mein wrote:
> I'm writing a function that will read data from the buffer in xlog (i.e.
> from XLogCtl->pages and XLogCtl->xlblocks). I want to make sure that I am
> doing it correctly.
> For reading from the buffer, do I need to lock WALInsertLock or
> WALWr
On Tue, Oct 26, 2010 at 5:01 AM, David Fetter wrote:
> Please find attached patch for $subject :)
Thank you for maintaining psql tab completion,
but I'm not sure whether tgtype is the best column for the purpose.
How about has_table_privilege() to filter candidate relations
in Query_for_list_of_i
On Mon, Oct 25, 2010 at 8:13 PM, Jeff Davis wrote:
> On Mon, 2010-10-25 at 18:03 -0400, Robert Haas wrote:
>> Hmm. Do you have some concrete examples of cases where a range type
>> might want to do some representational optimization?
>
> Let's say for instance you want to keep an timestamp range
On Oct 25, 2010, at 4:12 PM, Tom Lane wrote:
> However, that objection doesn't hold for plperl or pltcl (and likely
> not plpython, though I don't know that language enough to be sure).
> So it would be a reasonable feature request to teach those PLs to
> accept "record" parameters. I think the f
On Mon, Oct 25, 2010 at 5:24 PM, Jeff Davis wrote:
> I think that's easier when the PK must contain the FK, because then you
> only need to lock one record. Even when you need to lock multiple
> records, it seems feasible, and is just an index lookup, right? Do you
> see a particular problem?
Wel
On Mon, Oct 25, 2010 at 8:01 PM, Jeff Davis wrote:
> On Mon, 2010-10-25 at 18:28 -0400, Robert Haas wrote:
>> Oh, maybe I'm confused. Are you saying you'd need multiple copies of
>> the base type, or multiple range types based on a single base type?
>
> The latter. That is, if you want a timestam
On Mon, 2010-10-25 at 22:11 +0300, Peter Eisentraut wrote:
> Currently, foreign keys only work with the = operator (the name might be
> different, but it needs to behave like equality). I'm thinking there
> are other scenarios that could be useful, for example with arrays and
> range types.
I agr
On Mon, 2010-10-25 at 12:34 -0700, Greg Stark wrote:
> On Mon, Oct 25, 2010 at 12:11 PM, Peter Eisentraut wrote:
> > Is this sort of thing feasible? Has anyone done more research into the
> > necessary details?
>
> I think the problems arise when you try to figure out what records you
> need to
On Mon, 2010-10-25 at 18:03 -0400, Robert Haas wrote:
> Hmm. Do you have some concrete examples of cases where a range type
> might want to do some representational optimization?
Let's say for instance you want to keep an timestamp range in 16 bytes.
You could have an 8-byte timestamp, a 7-byte i
On Mon, 2010-10-25 at 18:28 -0400, Robert Haas wrote:
> Oh, maybe I'm confused. Are you saying you'd need multiple copies of
> the base type, or multiple range types based on a single base type?
The latter. That is, if you want a timestamp range with granularity 1
second, and a timestamp range wi
Merlin Moncure writes:
> probably hstore would be more appropriate for something like that.
An array is certainly completely the wrong thing if you don't intend
all the items to be the same datatype...
> You can also declare functions taking composite arrays, anyarray,
> variadic array, and vari
On Mon, Oct 25, 2010 at 6:38 PM, Greg wrote:
>
> Hi Pavel, thanks! Yeah, thats what I though. I have to have a custom type or
> a very ugly looking solution for passing the params then.
>
> To Postgre dev. team: If anyone who involved in Postgre development reading
> this, just a feature suggest
Anders Steinlein writes:
> http://archives.postgresql.org/pgsql-bugs/2010-03/msg00058.php
> This bit us hard (on PostgreSQL 8.4.4). We have a custom domain for
> email addresses based on citext, placed in the public schema, while each
> user of our application has their own private schemas. The
Hi Pavel, thanks! Yeah, thats what I though. I have to have a custom type or a
very ugly looking solution for passing the params then.
To Postgre dev. team: If anyone who involved in Postgre development reading
this, just a feature suggestion: allow array that can accept combination of any
data
On Mon, Oct 25, 2010 at 2:44 PM, Jeff Davis wrote:
> On Mon, 2010-10-25 at 14:11 -0400, Robert Haas wrote:
>> On Mon, Oct 25, 2010 at 2:01 PM, Jeff Davis wrote:
>> > On Mon, 2010-10-25 at 12:20 -0500, Kevin Grittner wrote:
>> >> It would be very useful to be able to specify a granularity -- for
>
Researching a nasty bug discovered in our application led me to this bug
report and its follow-ups:
http://archives.postgresql.org/pgsql-bugs/2010-03/msg00058.php
This bit us hard (on PostgreSQL 8.4.4). We have a custom domain for
email addresses based on citext, placed in the public schema, w
On Mon, Oct 25, 2010 at 2:27 PM, Jeff Davis wrote:
> On Mon, 2010-10-25 at 13:00 -0400, Robert Haas wrote:
>> I'm still confused. It seems to me (and maybe I'm full of it) that
>> the distinction between continuous ranges and discrete ranges is
>> pretty minor. Suppose you have continuous ranges
On Mon, Oct 25, 2010 at 4:35 PM, James Cloos wrote:
>> "TL" == Tom Lane writes:
>
> JC> That said, the possiblity of hex i/o format for the float datatypes
> JC> would be welcome.
>
> TL> It's unportable, for two different reasons:
>
> TL> 2. The printf specifiers you want us to rely on are n
On Mon, Oct 25, 2010 at 4:10 PM, Greg Stark wrote:
> On Mon, Oct 25, 2010 at 12:40 PM, Robert Haas wrote:
>> Now, as Greg says, that might be what some people want, but it's
>> certainly monumentally unserializable.
>
> To be clear when I said it's what people want what I meant was that in
> the
> "TL" == Tom Lane writes:
JC> That said, the possiblity of hex i/o format for the float datatypes
JC> would be welcome.
TL> It's unportable, for two different reasons:
TL> 2. The printf specifiers you want us to rely on are not standard.
They are in C99.
TL> 1. pg_dump output would becom
Andrew Dunstan writes:
> LABEL is already an unreserved keyword, and I'm pretty sure that's all
> we'll need.
The only reason it's a keyword is the SECURITY LABEL patch that went
in a month or so ago; which is syntax that might still be thought
better of before it gets to a release.
But I seem
Excerpts from Dimitri Fontaine's message of vie oct 22 16:43:56 -0300 2010:
> Dimitri Fontaine writes:
> > For information, when we talk about performance problem, please note
> > that on my workstation with a default setup (not that it's important
> > here) we're talking about 86,420 ms for a loo
Robert Haas wrote:
> Kevin Grittner wrote:
>> I would have thought that the INSERT would have
>> created an "in doubt" tuple which would block the UPDATE.
> This is just standard MVCC - readers don't block writers, nor
> writers readers.
Sure, but I tend to think of both INSERT and UPDATE a
On 10/25/2010 04:03 PM, Pavel Stehule wrote:
2010/10/25 Andrew Dunstan:
On 10/25/2010 02:51 PM, Robert Haas wrote:
Personally, I prefer LABEL. But I could live with VALUE.
That's roughly my position. It would be consistent with the name we use in
the catalogs, as well as what's in the doc
On Mon, Oct 25, 2010 at 12:40 PM, Robert Haas wrote:
> Now, as Greg says, that might be what some people want, but it's
> certainly monumentally unserializable.
To be clear when I said it's what people want what I meant was that in
the common cases it's doing exactly what people want. As opposed
2010/10/25 Robert Haas :
> On Mon, Oct 25, 2010 at 3:11 PM, Peter Eisentraut wrote:
>> Currently, foreign keys only work with the = operator (the name might be
>> different, but it needs to behave like equality). I'm thinking there
>> are other scenarios that could be useful, for example with arr
James Cloos writes:
> That said, the possiblity of hex i/o format for the float datatypes
> would be welcome.
It's unportable, for two different reasons:
1. pg_dump output would become platform-specific. This is highly
undesirable.
2. The printf specifiers you want us to rely on are not standa
2010/10/25 Andrew Dunstan :
>
>
> On 10/25/2010 02:51 PM, Robert Haas wrote:
>>
>> On Mon, Oct 25, 2010 at 2:41 PM, Tom Lane wrote:
>>>
>>> "David E. Wheeler" writes:
On Oct 25, 2010, at 10:08 AM, Tom Lane wrote:
>
> I can see the point of that, but I don't find LABEL to be a
>>
Folks,
Please find attached patch for $subject :)
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
> "JD" == Jeff Davis writes:
JD> 2. Fix the input/output functions in a special mode for dump/reload,
JD> to make them true inverses.
JC> That can be done by supporting the %A printf(3)/scanf(3) format.
JD> I don't happen to see a %A format in the man page, but I doubt the
JD> output would
Andrew Dunstan wrote:
>> Personally, I prefer LABEL. But I could live with VALUE.
>
> That's roughly my position.
LABEL would seem more natural to me. I would tend to think of the
VALUE as the hidden number which determines the order.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql
On 10/25/2010 02:51 PM, Robert Haas wrote:
On Mon, Oct 25, 2010 at 2:41 PM, Tom Lane wrote:
"David E. Wheeler" writes:
On Oct 25, 2010, at 10:08 AM, Tom Lane wrote:
I can see the point of that, but I don't find LABEL to be a particularly
great name for the elements of an enum type, and so
On Mon, Oct 25, 2010 at 3:11 PM, Peter Eisentraut wrote:
> Currently, foreign keys only work with the = operator (the name might be
> different, but it needs to behave like equality). I'm thinking there
> are other scenarios that could be useful, for example with arrays and
> range types.
>
> Exa
On Mon, Oct 25, 2010 at 3:15 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> rhaas=# create table concurrent (x integer primary key);
>> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
>> "concurrent_pkey" for table "concurrent"
>> CREATE TABLE
>> rhaas=# insert into x values (
On Mon, Oct 25, 2010 at 12:11 PM, Peter Eisentraut wrote:
> Is this sort of thing feasible? Has anyone done more research into the
> necessary details?
I think the problems arise when you try to figure out what records you
need to lock to prevent someone from deleting the referenced rows
before
Robert Haas wrote:
> rhaas=# create table concurrent (x integer primary key);
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> "concurrent_pkey" for table "concurrent"
> CREATE TABLE
> rhaas=# insert into x values (1);
> rhaas=# begin;
> BEGIN
> rhaas=# insert into concurrent v
Currently, foreign keys only work with the = operator (the name might be
different, but it needs to behave like equality). I'm thinking there
are other scenarios that could be useful, for example with arrays and
range types.
Example #1: Foreign key side is an array, every member must match some
P
On Mon, 2010-10-25 at 13:54 -0400, James Cloos wrote:
> > "JD" == Jeff Davis writes:
>
> JD> 2. Fix the input/output functions in a special mode for dump/reload,
> JD>to make them true inverses.
>
> That can be done by supporting the %A printf(3)/scanf(3) format.
I don't happen to see a
On Mon, Oct 25, 2010 at 2:41 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Oct 25, 2010, at 10:08 AM, Tom Lane wrote:
>>> I can see the point of that, but I don't find LABEL to be a particularly
>>> great name for the elements of an enum type, and so I'm not in favor of
>>> institutional
On Mon, 2010-10-25 at 14:11 -0400, Robert Haas wrote:
> On Mon, Oct 25, 2010 at 2:01 PM, Jeff Davis wrote:
> > On Mon, 2010-10-25 at 12:20 -0500, Kevin Grittner wrote:
> >> It would be very useful to be able to specify a granularity -- for
> >> example timestamps with a five minute granularity wou
"David E. Wheeler" writes:
> On Oct 25, 2010, at 10:08 AM, Tom Lane wrote:
>> I can see the point of that, but I don't find LABEL to be a particularly
>> great name for the elements of an enum type, and so I'm not in favor of
>> institutionalizing that name in the syntax. How about ADD VALUE?
>
> "JD" == Jeff Davis writes:
JD> 2. Fix the input/output functions in a special mode for dump/reload,
JD>to make them true inverses.
That can be done by supporting the %A printf(3)/scanf(3) format.
-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6
--
Sent via pgsql-hackers mailin
On Mon, 2010-10-25 at 13:00 -0400, Robert Haas wrote:
> I'm still confused. It seems to me (and maybe I'm full of it) that
> the distinction between continuous ranges and discrete ranges is
> pretty minor. Suppose you have continuous ranges done, and working.
> The only thing you need to add for
Pavel Stehule writes:
> DROP TABLE IF EXISTS foo;
> CREATE TABLE foo(a int, b int);
> INSERT INTO foo SELECT (random()*1)::int, (random()*10)::int from
> generate_series(1,10);
> ANALYZE foo;
> CREATE INDEX ON foo(a,b);
> CREATE INDEX ON foo(b,a);
> EXPLAIN SELECT max(a), b
>
On Mon, Oct 25, 2010 at 2:01 PM, Jeff Davis wrote:
> On Mon, 2010-10-25 at 12:20 -0500, Kevin Grittner wrote:
>> It would be very useful to be able to specify a granularity -- for
>> example timestamps with a five minute granularity would be useful
>> for scheduling appointments. In some cases the
On Mon, Oct 25, 2010 at 1:42 PM, Greg Stark wrote:
> On Sun, Oct 24, 2010 at 10:43 AM, Robert Haas wrote:
>> But let's back up and talk about MVCC for a minute. Suppose we have
>> three source tuples, (1), (2), and (3); and the target table contains
>> tuples (1) and (2), of which only (1) is vi
Greg Stark wrote:
> Robert Haas wrote:
>> But let's back up and talk about MVCC for a minute. Suppose we
>> have three source tuples, (1), (2), and (3); and the target table
>> contains tuples (1) and (2), of which only (1) is visible to our
>> MVCC snapshot; suppose also an equijoin. Clearly,
On Oct 25, 2010, at 10:08 AM, Tom Lane wrote:
> I can see the point of that, but I don't find LABEL to be a particularly
> great name for the elements of an enum type, and so I'm not in favor of
> institutionalizing that name in the syntax. How about ADD VALUE?
From the fine manual:
> The secon
On Mon, 2010-10-25 at 12:20 -0500, Kevin Grittner wrote:
> It would be very useful to be able to specify a granularity -- for
> example timestamps with a five minute granularity would be useful
> for scheduling appointments. In some cases the granularity might be
> inferred -- if we have a domain d
On Sun, Oct 24, 2010 at 10:43 AM, Robert Haas wrote:
> But let's back up and talk about MVCC for a minute. Suppose we have
> three source tuples, (1), (2), and (3); and the target table contains
> tuples (1) and (2), of which only (1) is visible to our MVCC snapshot;
> suppose also an equijoin.
Brendan Jurd writes:
> This whole business of passing around global pointers while switching
> memory contexts seems like an optimal breeding-ground for bugs.
Yeah. If it were to get significantly more complicated than this,
the best solution IMO would be to give up on trying to use a temporary
Jeff Davis wrote:
> Last development cycle, one of the questions that was unresolved
> was whether to handle ranges like a discrete set (that is, [1,5) =
> [1,4] ) or continuous or both.
>
> I think that discrete ranges are required. For instance, day range
> and IP address ranges are two examp
On 26 October 2010 03:42, Tom Lane wrote:
> Brendan Jurd writes:
>> Thanks for the hint; I found that the attached patch resolved my
>> specific segfault, but I am wondering whether it goes far enough.
>
> Well, it definitely doesn't go far enough, because the invalItems list
> has to be restored
Andrew Dunstan writes:
> It occurred to me in the dead of the night that instead of:
> ALTER TYPE enumtype ADD 'newlabel'
> it might be better to have:
> ALTER TYPE enumtype ADD LABEL 'newlabel'
> That way if we later wanted to support some other sort of ADD operation
> on types we would
On Mon, Oct 25, 2010 at 12:51 PM, Jeff Davis wrote:
> On Sun, 2010-10-24 at 18:59 -0400, Tom Lane wrote:
>> Jeff Davis writes:
>> > Last development cycle, one of the questions that was unresolved was
>> > whether to handle ranges like a discrete set (that is, [1,5) = [1,4] )
>> > or continuous o
On mån, 2010-10-25 at 09:33 -0400, Robert Haas wrote:
> It seems we're still missing some relevant details, because hdparm
> doesn't seem to work on SCSI devices. Is sdparm the right utility in
> that case? Does anyone know what the correct incantations look like?
Search the sdparm man page for
On Sun, 2010-10-24 at 18:59 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > Last development cycle, one of the questions that was unresolved was
> > whether to handle ranges like a discrete set (that is, [1,5) = [1,4] )
> > or continuous or both.
>
> Put me in the camp that says you need both. I
Hello
I am thinking, so it isn't possible. There are a general datatype
anyelement, but it cannot accept a second general type record.
CREATE TYPE p AS (a text, b int, c bool);
CREATE OR REPLACE FUNCTION fp(p)
RETURNS int AS $$
BEGIN RAISE NOTICE 'a = %', $1.a; RETURN $1.b;
END;
$$ LANGUAGE plpg
On mån, 2010-10-25 at 11:48 -0400, Andrew Dunstan wrote:
> It occurred to me in the dead of the night that instead of:
>
> ALTER TYPE enumtype ADD 'newlabel'
>
>
> it might be better to have:
>
> ALTER TYPE enumtype ADD LABEL 'newlabel'
That had occurred to me as well. Go for it.
-
Brendan Jurd writes:
> On 25 October 2010 07:36, Tom Lane wrote:
>> I'm guessing it was modified in the temporary memory context and not
>> properly copied out to the parent context when we finished inlining
>> the function.
> Thanks for the hint; I found that the attached patch resolved my
> sp
On Mon, Oct 25, 2010 at 11:57 AM, Pavel Stehule wrote:
> 2010/10/25 Andrew Dunstan :
>>
>> It occurred to me in the dead of the night that instead of:
>>
>> ALTER TYPE enumtype ADD 'newlabel'
>>
>>
>> it might be better to have:
>>
>> ALTER TYPE enumtype ADD LABEL 'newlabel'
>
> +1
+1.
--
R
Hi guys, got across an interesting problem of passing params to a function in
postgre: is it possible to pass a composite parameter to a function without
declaring a type first?
For example:
// declare a function
create function TEST ( object??? )
object???.paramName // using par
2010/10/25 Andrew Dunstan :
>
> It occurred to me in the dead of the night that instead of:
>
> ALTER TYPE enumtype ADD 'newlabel'
>
>
> it might be better to have:
>
> ALTER TYPE enumtype ADD LABEL 'newlabel'
+1
Regards
Pavel
>
>
> That way if we later wanted to support some other sort of A
It occurred to me in the dead of the night that instead of:
ALTER TYPE enumtype ADD 'newlabel'
it might be better to have:
ALTER TYPE enumtype ADD LABEL 'newlabel'
That way if we later wanted to support some other sort of ADD operation
on types we would be able to more easily. LABEL
On 25 October 2010 07:36, Tom Lane wrote:
> Brendan Jurd writes:
>> I have encountered a reproducible segfault in Postgres ...
>
> Looks like the invalItems list has been clobbered:
>
> (gdb) p *root->glob->invalItems
> $6 = {type = 2139062143, length = 2139062143, head = 0x7f7f7f7f,
> tail = 0x
On Mon, Oct 25, 2010 at 10:21:49AM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Sun, Oct 24, 2010 at 06:59:34PM -0400, Tom Lane wrote:
> >> Put me in the camp that says you need both. I really seriously
> >> dislike the idea of representing [1, 2) as [1, 2-epsilon], mainly
> >> because th
postgres=# \i crash.sql
version
──
PostgreSQL 9.1devel on x86_64-unknown-linux-gnu, compiled by GCC gcc
(GCC) 4.4.4 20100630 (Red Hat 4.4.4…
…-10
Itagaki Takahiro writes:
> SQL/MED will have some kinds of planner hooks to support FDW-depending
> plan execution. Then, we will need to support user-defined executor nodes.
> The proposed SQL/MED has own "executor node hooks" in ForeignTableScan,
> http://wiki.postgresql.org/wiki/SQL/MED#Execu
Excerpts from Alvaro Herrera's message of lun oct 25 10:37:22 -0300 2010:
> Excerpts from Alvaro Herrera's message of vie oct 22 17:02:22 -0300 2010:
>
> > > I'll go rework the patch sometime later to drop the name from the
> > > control file, but that also means fixing several contrib modules by
Pavel Stehule writes:
> On 9.1 I found a query where explain do backend crash
Can't reproduce here. Would you provide a self-contained test case?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
David Fetter writes:
> On Sun, Oct 24, 2010 at 06:59:34PM -0400, Tom Lane wrote:
>> Put me in the camp that says you need both. I really seriously
>> dislike the idea of representing [1, 2) as [1, 2-epsilon], mainly
>> because there is often no portable value for epsilon.
>> Dump-and-restore woul
Excerpts from Alvaro Herrera's message of vie oct 22 17:02:22 -0300 2010:
> Excerpts from Dimitri Fontaine's message of vie oct 22 16:21:14 -0300 2010:
> > I'll go rework the patch sometime later to drop the name from the
> > control file, but that also means fixing several contrib modules by
> >
On Tue, Oct 19, 2010 at 11:06 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Thu, Oct 7, 2010 at 11:52 AM, Tom Lane wrote:
>> > Robert Haas writes:
>> >> Proposed doc patch attached.
>> >
>> > "discusesed"? ?Otherwise +1
>>
>> Woops, thanks. Committed with that change. I back-patched it b
Excerpts from Alvaro Herrera's message of jue oct 21 18:06:40 -0300 2010:
> Excerpts from Tom Lane's message of jue oct 21 17:48:18 -0300 2010:
> > buildfarm member koi, having recently been rescued from git purgatory,
> > is failing like this:
> > which indicates it can't cope with your recent pa
Hello
> 4) List of foreign connections
> Users (especially DBAs?) might want to see list of foreign connections.
> Currently postgresql_fdw provides its own connection list via
> postgresql_fdw_connections view. Common view such as
> pg_foreign_connections would be needed? If so, function which
Sorry for this late responding. I got a cold later half of the last week.
(2010/10/20 12:10), Robert Haas wrote:
On Wed, Oct 13, 2010 at 2:13 AM, Robert Haas wrote:
2010/8/24 KaiGai Kohei:
I tried to revise the patch. It allows plugins to get control next to
client authentication, but before
Hello
On 9.1 I found a query where explain do backend crash
backtrace
Core was generated by `postgres: pavel postgres [local] EXPLAIN
'.
Program terminated with signal 6, Aborted.
#0 0x003226c329a5 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install
Robert Haas wrote:
> What we're talking about is what happens when there are concurrent
> table modifications in progress; and the answer is that you might
> get serialization anomalies. But we have serialization anomalies
> without MERGE, too - see the discussions around Kevin Grittner's
> SSI
node->plan->vtable->ReScan(node);
...
--
Itagaki Takahiro
extensible_execnodes-20101025.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 25.10.2010 01:59, Tom Lane wrote:
Jeff Davis writes:
If we treat those as discrete, then R1 = R2, R1 contains R2, R2 contains
R1, and R2 - R1 = R1 - R2 = empty. However, if we treat those as
continuous, then we get a contradiction:
R2 contains R1
R1 does not contain R2
R2 - R1 = ( 2009
88 matches
Mail list logo
