We have infrastructure to count numbers buffer access in 8.5 Alpha 3.
I'd like to add per-query buffer usage into contrib/pg_stat_statements.
The pg_stat_statements view will have the same contents with
struct BufferUsage. Fields named shared_blks_{hit|read|written},
(2009/12/18 15:48), Takahiro Itagaki wrote:
Robert Haasrobertmh...@gmail.com wrote:
In both cases, I'm lost. Help?
They might be contrasted with the comments for myLargeObjectExists.
Since we use MVCC visibility in loread(), metadata for large object
also should be visible in MVCC
Le vendredi 18 décembre 2009 09:44:40, Takahiro Itagaki a écrit :
We have infrastructure to count numbers buffer access in 8.5 Alpha 3.
I'd like to add per-query buffer usage into contrib/pg_stat_statements.
The pg_stat_statements view will have the same contents with
struct BufferUsage.
This way we only cancel direct deadlocks.
It doesn't solve general problem of buffer waits, but they may be
solvable by different mechanism.
Following question may be redundant. Just a confirmation.
Deadlock example is catstrophic while it's rather a rare event.
On the other hand,
On ons, 2009-12-16 at 11:28 -0800, David E. Wheeler wrote:
I just realized that this was easy to do, and despite my complete lack of C
skillz was able to throw this together in a couple of hours. It might be
handy to some, though the possible downsides are:
* No json_to_hstore().
* Leads
On ons, 2009-12-16 at 15:42 +, Simon Riggs wrote:
I suggest we say smoothed when checkpoint option is !immediate. So
we
will remove the word immediate from the message.
The opposite of smooth could be sharp. :)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Pavel Stehule wrote:
2009/12/17 Andrew Dunstan and...@dunslane.net:
Recently there was discussion about allowing a COPY statement to be a SELECT
target, returning a text array, although the syntax wasn't really nailed
down that I recall. I was thinking that we might have
COPY RETURNING
2009/12/18 KaiGai Kohei kai...@ak.jp.nec.com:
(2009/12/18 15:48), Takahiro Itagaki wrote:
Robert Haasrobertmh...@gmail.com wrote:
In both cases, I'm lost. Help?
They might be contrasted with the comments for myLargeObjectExists.
Since we use MVCC visibility in loread(), metadata for
* Florian Pflug:
On 16.12.09 16:40 , Kevin Grittner wrote:
Nicolas Barbiernicolas.barb...@gmail.com wrote:
I am not sure whether the serialization failures that it may cause
are dependent on the plan used.
They are.
But so are failures due to deadlocks even today, no?
They are
Fujii Masao wrote:
pg_stop_backup deletes the previous backup history file from pg_xlog.
So replication of a backup history file would fail if just one new
online-backup is caused after the base-backup for the standby is taken.
This is too aggressive deletion policy for Streaming Replication,
On Fri, Dec 18, 2009 at 11:03 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Or some way for to register the standby with the master so that
the master knows it's out there, and still needs the logs, even when
it's not connected.
That is the real answer, I think.
...Robert
On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
Should we create a json type before adding all kinds of json formatted
data? Or are we content with json as text?
json_data_type++
D
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
2009/12/18 Florian Weimer fwei...@bfk.de:
* Florian Pflug:
On 16.12.09 16:40 , Kevin Grittner wrote:
Nicolas Barbiernicolas.barb...@gmail.com wrote:
I am not sure whether the serialization failures that it may cause
are dependent on the plan used.
They are.
But so are failures due
Hi!
I just want to distinguish a view and a table while postgres execute
exec_simple_query(). In the systable of pg_class, a view and a table has
different relkind ('r' 'v'). But when I print the parsetree and the rewrite
parsetree, I found that a view and a table has no character to
2009/12/18 suzhiyang suzhiy...@gmail.com
How could I get the relkind of a table(view) by its name from pg_class?
pg_class is (quite logically) UNIQUE on (relname, relnamespace)
SELECT c.relkind from pg_class c, pg_namespace n
where c.relnamespace = n.oid
and c.relname = 'thetable'
and
On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler da...@kineticode.com wrote:
On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
Should we create a json type before adding all kinds of json formatted
data? Or are we content with json as text?
json_data_type++
What would that do for us?
On 18.12.09 16:42 , Florian Weimer wrote:
* Florian Pflug:
On 16.12.09 16:40 , Kevin Grittner wrote:
Nicolas Barbiernicolas.barb...@gmail.com wrote:
I am not sure whether the serialization failures that it may cause
are dependent on the plan used.
They are.
But so are failures due to
On Dec 18, 2009, at 8:51 AM, Robert Haas wrote:
What would that do for us?
I'm not opposed to it, but it seems like the more important thing
would be to provide functions or operators that can do things like
extract an array, extract a hash key, identify whether something is a
hash, list,
I'm trying to implement a function that has some XA like properties.
Is it possible to write a postgres extension function that fires when called
within a pg transaction... however, the actions it takes need to be later
committed or rolled back based on the containing transactions commital or
On current Fedora 11, there is a huge difference in initdb time if you
have TZ set versus if you don't: I get about 18 seconds versus less than
four.
$ time initdb
... blah blah blah ...
real0m17.953s
user0m6.490s
sys 0m10.935s
$ rm -rf $PGDATA
$ export TZ=GMT
$ time initdb
... blah
On 18.12.09 17:33 , Nicolas Barbier wrote:
I would guess that currently, whether deadlocks can be triggered by
a set of transactions (i.e., sequences of SQL statements) depends on
the plan only marginally*. E.g., if two plans happen to use the same
index, rows may always get locked in the same
Le 18/12/2009 18:07, Tom Lane a écrit :
On current Fedora 11, there is a huge difference in initdb time if you
have TZ set versus if you don't: I get about 18 seconds versus less than
four.
$ time initdb
... blah blah blah ...
real0m17.953s
user0m6.490s
sys 0m10.935s
$ rm
On 18.12.09 17:05 , Robert Haas wrote:
On Fri, Dec 18, 2009 at 11:03 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Or some way for to register the standby with the master so that
the master knows it's out there, and still needs the logs, even when
it's not connected.
That
On Fri, Dec 18, 2009 at 12:22 PM, Florian Pflug fgp.phlo@gmail.com wrote:
On 18.12.09 17:05 , Robert Haas wrote:
On Fri, Dec 18, 2009 at 11:03 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Or some way for to register the standby with the master so that
the master
On Fri, Dec 18, 2009 at 10:57 AM, suzhiyang suzhiy...@gmail.com wrote:
Another question is that does postgres save the user's original query_string
at anywhere(systable etc.)? If I want to save the sourceText in the
systable, I could add a column to pg_class called query_string. How could I
On Fri, Dec 18, 2009 at 06:20:39PM +0100, Guillaume Lelarge wrote:
Le 18/12/2009 18:07, Tom Lane a écrit :
On current Fedora 11, there is a huge difference in initdb time if you
have TZ set versus if you don't: I get about 18 seconds versus less than
four.
I have the exact same issue:
For
suzhiyang suzhiy...@gmail.com writes:
I just want to distinguish a view and a table while postgres execute
exec_simple_query(). In the systable of pg_class, a view and a table
has different relkind ('r' 'v'). But when I print the parsetree and
the rewrite parsetree, I found that a view and a
Tom Lane wrote:
On current Fedora 11, there is a huge difference in initdb time if you
have TZ set versus if you don't: I get about 18 seconds versus less than
four.
Wow, I can reproduce this (11-12 secs when no TZ versus 5 when TZ is
defined). I'd never noticed because I normally have TZ
Florian Weimer fwei...@bfk.de wrote:
* Florian Pflug:
On 16.12.09 16:40 , Kevin Grittner wrote:
Nicolas Barbiernicolas.barb...@gmail.com wrote:
I am not sure whether the serialization failures that it may
cause are dependent on the plan used.
They are.
But so are failures due to
Joshua Tolley eggyk...@gmail.com writes:
On Fri, Dec 18, 2009 at 06:20:39PM +0100, Guillaume Lelarge wrote:
Le 18/12/2009 18:07, Tom Lane a écrit :
On current Fedora 11, there is a huge difference in initdb time if you
have TZ set versus if you don't: I get about 18 seconds versus less than
Alvaro Herrera alvhe...@commandprompt.com writes:
I notice that most of the difference is system time ... I imagine we do
a lot of syscalls to guess the timezone.
Yeah, it seems to be mostly the cost of searching the timezone directory
tree and reading all those small files. I was led to
Robert Haas wrote:
On Fri, Dec 18, 2009 at 12:22 PM, Florian Pflug fgp.phlo@gmail.com
wrote:
On 18.12.09 17:05 , Robert Haas wrote:
On Fri, Dec 18, 2009 at 11:03 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Or some way for to register the standby with the master so
Theo Schlossnagle wrote:
I'm trying to implement a function that has some XA like properties.
Is it possible to write a postgres extension function that fires when called
within a pg transaction... however, the actions it takes need to be later
committed or rolled back based on the
Robert Haas wrote:
On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler da...@kineticode.com wrote:
On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
Should we create a json type before adding all kinds of json formatted
data? Or are we content with json as text?
On Tue, Dec 15, 2009 Greg Smith wrote:
Sounds like we just are waiting for Simon to finish up, which is
expected to happen by tomorrow, and for Tom to wrap up working on the
ProcessUtility_hook. That makes the first reasonable date to consider
alpha3 packaging Thursday 12/17 I think.
This is perfect. It fires on both commit and rollback? And I can
determine which? The system I'm interfacing with has 2PC so it should
be a pretty tight fit. Thanks a ton Heikki!
--
Theo Schlossnagle (mobile)
http://omniti.com/is/theo-schlossnagle
On Dec 18, 2009, at 10:34 AM, Heikki
Andrew Dunstan and...@dunslane.net writes:
You're correct that we don't necessarily need a new type, we could just
make it text and have a bunch of operations, but that seems to violate
the principle of data type abstraction a bit.
I think the relevant precedent is that we have an xml type.
There are several pg_migrator limitations that appeared late in the 8.4
development cycle and were impossible to fix at that point. I would
like to fix them for Postgres 8.5:
o a user-defined composite data type
o a user-defined array data type
o a user-defined enum
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
You're correct that we don't necessarily need a new type, we could just
make it text and have a bunch of operations, but that seems to violate
the principle of data type abstraction a bit.
I think the relevant precedent is
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
You're correct that we don't necessarily need a new type, we could just
make it text and have a bunch of operations, but that seems to violate
the principle of data type abstraction a bit.
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
[ I can already hear somebody insisting on a yaml type :-( ]
Now that's a case where I think a couple of converter functions at most
should meet the need.
Well, actually, now that you mention it: how much of a json type would
be
Bruce Momjian wrote:
There are several pg_migrator limitations that appeared late in the 8.4
development cycle and were impossible to fix at that point. I would
like to fix them for Postgres 8.5:
o a user-defined composite data type
o a user-defined array data type
Tom Lane escribió:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
[ I can already hear somebody insisting on a yaml type :-( ]
Now that's a case where I think a couple of converter functions at most
should meet the need.
Well, actually, now that you mention it: how much
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Well, actually, now that you mention it: how much of a json type would
be duplicative of the xml stuff? Would it be sufficient to provide
json - xml converters and let the latter type do all the heavy lifting?
(If so, this
Hi,
Le 18 déc. 2009 à 19:21, Heikki Linnakangas a écrit :
On Fri, Dec 18, 2009 at 12:22 PM, Florian Pflug fgp.phlo@gmail.com
wrote:
It'd prefer if the slave could automatically fetch a new base backup if it
falls behind too far to catch up with the available logs. That way, old logs
Alvaro Herrera wrote:
Bruce Momjian wrote:
There are several pg_migrator limitations that appeared late in the 8.4
development cycle and were impossible to fix at that point. I would
like to fix them for Postgres 8.5:
o a user-defined composite data type
o a
I wrote:
[for a description of traditional techniques for providing various
isolation levels, including serializable], Dr. Cahill seemed to
like (Hellerstein et al., 2007)
If anyone else is interested in this paper, here is additional
information:
Architecture of a Database System.
Hi all!
Infrastructure monitoring started to complain a few days ago that we
failed generating new snapshot-tarball for HEAD.
Manual investigation shows that the script dies while building the docs
with:
openjade:installation.sgml:202:51:X: reference to non-existent ID
PLPYTHON-PYTHON23
On Fri, Dec 18, 2009 at 3:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Well, actually, now that you mention it: how much of a json type would
be duplicative of the xml stuff? Would it be sufficient to provide
json - xml
+1 for such a feature, simply to avoid the need of
writing a hstore-parser (which wasn't too bad
to write, but it felt unnecessary). Doesn't
matter to me if it's hstore-to-json or hstore-to-xml
or hstore-to-yaml. Just something that parsers are
readily available for.
Heck, I wouldn't mind if
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
openjade:installation.sgml:202:51:X: reference to non-existent ID
PLPYTHON-PYTHON23
openjade:/usr/local/share/sgml/docbook/dsssl/modular/html/dblink.dsl:203:1:E:
XRef LinkEnd to missing ID 'PLPYTHON-PYTHON23'
Looks like Peter forgot about
Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I installed PL/pgSQL by default via initdb with the attached patch. The
only problem is that pg_dump still dumps out the language creation:
CREATE PROCEDURAL LANGUAGE
On fre, 2009-12-18 at 11:51 -0500, Robert Haas wrote:
On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler da...@kineticode.com
wrote:
On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
Should we create a json type before adding all kinds of json formatted
data? Or are we content with
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
There are several pg_migrator limitations that appeared late in the 8.4
development cycle and were impossible to fix at that point. I would
like to fix them for Postgres 8.5:
o a user-defined composite
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
There are several pg_migrator limitations that appeared late in the 8.4
development cycle and were impossible to fix at that point. I would
like to fix them for Postgres 8.5:
o
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
To be more precise, the pg_enum.oid needs to be set for ENUM types;
there's no need for setting the pg_type.oid (for ENUM types). I don't
know about composites but I think the problem with
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
To be more precise, the pg_enum.oid needs to be set for ENUM types;
there's no need for setting the pg_type.oid (for ENUM types). I don't
know about composites
Bruce Momjian wrote:
There are several pg_migrator limitations that appeared late in the 8.4
development cycle and were impossible to fix at that point. I would
like to fix them for Postgres 8.5:
o a user-defined composite data type
o a user-defined array data type
On Fri, Dec 18, 2009 at 4:39 PM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2009-12-18 at 11:51 -0500, Robert Haas wrote:
On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler da...@kineticode.com
wrote:
On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
Should we create a json type
On Fri, Dec 18, 2009 at 4:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Looks like Peter forgot about the restrictions on links in doc sections
that also get made into standalone text files. Will fix.
I seem to have... forgotten... those as well. Can you enlighten me?
...Robert
--
Sent via
On Fri, Dec 18, 2009 at 6:44 PM, Andrew Dunstan and...@dunslane.net wrote:
I thought there was a suggestion that we would be able to specify the oids
in the SQL that creates the types, along the lines of:
create type foo as enum ( ...) with oids ( ... );
Is that a non-starter? I imagine it
Robert Haas wrote:
On Fri, Dec 18, 2009 at 3:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Well, actually, now that you mention it: how much of a json type would
be duplicative of the xml stuff? Would it be
Bruce Momjian wrote:
Seems I need some help here.
I'm willing to work on this --- it doesn't look particularly fun but
we really need it.
Andrew Dunstan and...@dunslane.net writes:
I thought there was a suggestion that we would be able to specify the
oids in the SQL that creates the types,
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 18, 2009 at 4:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Looks like Peter forgot about the restrictions on links in doc sections
that also get made into standalone text files. Will fix.
I seem to have... forgotten... those as well. Can
On Fri, Dec 18, 2009 at 7:05 PM, Andrew Dunstan and...@dunslane.net wrote:
One problem is that there is not a single well-defined mapping between
these types. I would say generally that XML and YAML both have more
types of constructs than JSON. The obvious ways of translating an
arbitrary
Tom Lane wrote:
* ability to control the OIDs assigned to user tables and types.
Because a table also has a rowtype, this means at least two separate
state variables. And we already knew we had to control the OIDs
assigned to toast tables. I'm imagining dump output like
select
Tom Lane wrote:
At the moment it appears that we need the following hacks:
* ability to control the OIDs assigned to user tables and types.
Because a table also has a rowtype, this means at least two separate
state variables. And we already knew we had to control the OIDs
assigned to toast
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
select pg_migrator_set_next_table_oid(123456);
select pg_migrator_set_next_type_oid(12347);
select pg_migrator_set_next_toast_table_oid(123458);
CREATE TABLE ...
Do we also need a knob for the table type's array type?
Dimitri Fontaine escribió:
Well I did propose to consider a state machine with clear transition for such
problems, a while ago, and I think my remarks still do apply:
http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg131511.html
Sorry for non archives.postgresql.org link,
Bruce Momjian wrote:
I think the OIDs for user-defined arrays stored in table data are
element types, not the array type which is what you're pointing at with
the line you quote:
array_oid = GetNewOid(pg_type);
IMBFOS.
Oh, yea, sorry, I was just showing examples of
Tom Lane wrote:
The more I think about it the less I want such warts placed in the
regular SQL syntax for creation commands. As soon as we add a wart like
that we'll be stuck with supporting it forever. Whatever we do here
should be off in a little corner that only pg_migrator can get at.
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
select pg_migrator_set_next_table_oid(123456);
select pg_migrator_set_next_type_oid(12347);
select pg_migrator_set_next_toast_table_oid(123458);
CREATE TABLE ...
Do we also need a knob for the table
On 12/18/2009 04:09 PM, Tom Lane wrote:
At the moment it appears that we need the following hacks:
* ability to control the OIDs assigned to user tables and types.
Because a table also has a rowtype, this means at least two separate
state variables. And we already knew we had to control the
Bruce Momjian br...@momjian.us writes:
... The idea I had was to create a global structure:
struct pg_migrator_oids {
Oid pg_type;
Oid pg_type_array;
...
}
This would initialize to zero as a global structure, and only
Joe Conway m...@joeconway.com writes:
I like this approach overall, but wonder if it would be better to do:
select pg_migrator_set_next_oid('table', 123456);
select pg_migrator_set_next_oid('type', 12347);
select pg_migrator_set_next_oid('toast_table', 123458);
etc. Later we
On Fri, Dec 18, 2009 at 9:00 AM, Robert Haas robertmh...@gmail.com wrote:
2009/12/18 KaiGai Kohei kai...@ak.jp.nec.com:
(2009/12/18 15:48), Takahiro Itagaki wrote:
Robert Haasrobertmh...@gmail.com wrote:
In both cases, I'm lost. Help?
They might be contrasted with the comments for
On Fri, Dec 18, 2009 at 1:48 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
In both cases, I'm lost. Help?
They might be contrasted with the comments for myLargeObjectExists.
Since we use MVCC visibility in loread(), metadata for large object
also should be visible in MVCC rule.
On Fri, Dec 18, 2009 at 8:32 PM, Simon Riggs sri...@postgresql.org wrote:
Log Message:
---
Allow read only connections during recovery, known as Hot Standby.
Enabled by recovery_connections = on (default) and forcing archive recovery
using a recovery.conf. Recovery processing now
Robert Haas robertmh...@gmail.com writes:
Oh. This is more complicated than it appeared on the surface. It
seems that the string BLOB COMMENTS actually gets inserted into
custom dumps somewhere, so I'm not sure whether we can just change it.
Was this issue discussed at some point before
Robert Haas robertmh...@gmail.com writes:
Part of what I'm confused about (and what I think should be documented
in a comment somewhere) is why we're using MVCC visibility in some
places but not others. In particular, there seem to be some bits of
the comment that imply that we do this for
I'm doing the Todo List's Allow VIEW/RULE recompilation when the underlying
tables change . I've a very simple idea that I save the create view
query_string in systable. When I found that I select from a view, I drop the
view and recreate the view by execute the source query_string. Then go on
On Fri, Dec 18, 2009 at 9:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Oh. This is more complicated than it appeared on the surface. It
seems that the string BLOB COMMENTS actually gets inserted into
custom dumps somewhere, so I'm not sure whether we
On Fri, Dec 18, 2009 at 9:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Part of what I'm confused about (and what I think should be documented
in a comment somewhere) is why we're using MVCC visibility in some
places but not others. In particular, there
On Fri, Dec 18, 2009 at 9:58 PM, suzhiyang suzhiy...@gmail.com wrote:
I'm doing the Todo List's Allow VIEW/RULE recompilation when the underlying
tables change . I've a very simple idea that I save the create view
query_string in systable. When I found that I select from a view, I drop the
Yeah, when a column of the underlying table renamed, this re-executing must be
failed...
2009-12-19
suzhiyang
发件人： Robert Haas
发送时间： 2009-12-19 11:17:44
收件人： suzhiyang
抄送： pgsql-hackers
主题： Re: [HACKERS] About Allow VIEW/RULE recompilation when theunderlying
tables change
On
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 18, 2009 at 9:58 PM, suzhiyang suzhiy...@gmail.com wrote:
I'm doing the Todo List's Allow VIEW/RULE recompilation when the underlying
tables change .
I am not sure what this TODO item is supposed to refer to, but saving
the query string
On Fri, Dec 18, 2009 at 10:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 18, 2009 at 9:58 PM, suzhiyang suzhiy...@gmail.com wrote:
I'm doing the Todo List's Allow VIEW/RULE recompilation when the underlying
tables change .
I am not sure what
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 18, 2009 at 10:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The TODO item is terribly underdocumented, but I think what it's on
about is that right now we refuse commands like ALTER COLUMN TYPE if
the column is referenced in a view. It would
On Fri, Dec 18, 2009 at 11:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 18, 2009 at 10:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The TODO item is terribly underdocumented, but I think what it's on
about is that right now we refuse commands
Robert Haas wrote:
On Mon, Dec 14, 2009 at 12:38 PM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
I don't think there should be a transition from Returned with Feedback
back to Waiting for review. Granted we might allow that occasionally
as an exceptional case, but
Hi,
I couldn't find lo_import(text, oid) document anywhere in the
PostgreSQL core documents. Unless I'm missing something, I would like
to add description for the function in 31.4. Server-Side Functions
part.
BTW, why don't lo_creat, lo_create, lo_unlink, lo_import and lo_export
server side
CommitFest 2009-11 is now closed, having committed 27 patches in 33
days. For comparison sake, 2009-09 committed 20 patches in 29 days,
2009-07 37 patches in 34 days, and 2008-09 29 patches in 30 days. The
much bigger 2008-11 involved 58 patches going on for months, the bulk of
it committed
92 matches
Mail list logo
