Hi,
On Thu, Nov 12, 2009 at 4:32 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
The problem is that fsync needs to be issued too frequently, which would
be harmless in asynchronous replication, but not in synchronous one.
A transaction would have to wait
On Thu, 2009-11-12 at 17:03 +0900, Fujii Masao wrote:
On Thu, Nov 12, 2009 at 4:32 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
The problem is that fsync needs to be issued too frequently, which would
be harmless in asynchronous replication, but not
On Sun, 2009-11-08 at 20:52 -0500, Robert Haas wrote:
I would personally prefer not to be involved in the management of the
next CommitFest. Having done all of the July CommitFest and a good
chunk of the September CommitFest, I am feeling a bit burned out.
You did a grand job and everybody
Alvaro Herrera írta:
Boszormenyi Zoltan escribió:
I have split up (and cleaned up a little) the dynamic
cursorname patch into smaller logical, easier-to-review
pieces. Descriptions below.
1) 1a-unified-optfromin-fetch-ctxdiff.patch
ecpg supports optional FROM/IN in FETCH and
MOVE
Alvaro Herrera írta:
Boszormenyi Zoltan escribió:
2) 1b-cursor_name-ctxdiff.patch
name - cursor_name transition in core grammar
and ecpg grammar. Currently it does nothing, it's a
preparation phase. Depends on patch 1.
Applied this part too.
I cannot apply the other ones --
On Thu, Nov 12, 2009 at 2:12 AM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Does it cope with the case where a trigger is doing NOTIFY, and you do
a whole-table update, therefore dumping potentially millions of
notifications in at once?
(for example a rare maintenance operation on a
Bruce Momjian br...@momjian.us writes:
Peter Eisentraut wrote:
discernible benefits. But you can't expect a lot of people or employers
to reserve time on top of that for handholding other people's patches
and for other community stuff that has no easy to measure benefits.
Totally agree.
Hi,
Josh Berkus j...@agliodbs.com writes:
Let's NOT start that discussion again.
Don't worry, no aim here to.
Overall, I'm seeing this patch proposal suffer from an extreme excess of
bike-shedding.
Not only that. See above.
My proposal is this:
(1) that we support the idea of a patch
On Thu, Nov 12, 2009 at 4:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
One possible solution would be to write to the queue before committing
and adding the TransactionID. Then other backends can check if our
TransactionID has successfully committed or not. Not sure if this is
worth the overhead
On Thu, Nov 12, 2009 at 5:04 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Sun, 2009-11-08 at 20:52 -0500, Robert Haas wrote:
I would personally prefer not to be involved in the management of the
next CommitFest. Having done all of the July CommitFest and a good
chunk of the September
Hi,
On Thursday 12 November 2009 12:46:46 Robert Haas wrote:
Perhaps for next release we should consider spacing the CommitFests
out a little more.
That may lead to quite a bit frustration on the contributor side though. It
can be very frustrating to have no input for a even longer
On Thu, Nov 12, 2009 at 6:49 AM, Andres Freund and...@anarazel.de wrote:
On Thursday 12 November 2009 12:46:46 Robert Haas wrote:
Perhaps for next release we should consider spacing the CommitFests
out a little more.
That may lead to quite a bit frustration on the contributor side though. It
On Thu, Nov 12, 2009 at 6:27 PM, Simon Riggs si...@2ndquadrant.com wrote:
I agree with you, though it has taken some time to understand what you
said and at first my reaction was to disagree. I think the responses you
got on this are because you dived straight in with a question before
On Thu, 2009-11-12 at 21:45 +0900, Fujii Masao wrote:
But, as I said on my first post on this thread, even such low-frequent
fsync-WAL-before-buffer-flush might cause a response time spike on the
primary because the walreceiver must sleep during that fsync. I think
that leaving the
Itagaki Takahiro wrote:
Here is a patch to support rewrite version of VACUUM FULL.
It was called VACUUM REWRITE in the past disucussin,
but I choose the following syntax for now:
VACUUM ( FULL [ INPLACE | REPLACE ] ) [ table_name ]
The reason is to contrast the new REPLACE behavior
Itagaki Takahiro wrote:
We still need traditional VACUUM FULL behavior for system catalog because
we cannot change relfilenode for them. Also, VACUUM FULL REPLACE is not
always better than traditional VACUUM FULL; the new version requires
additional disk space and might be slower if we have a
BTW I think the vacstmt.options change, which seems a reasonable idea to
me, could be extracted from the patch and applied separately. That'd
reduce the size of the patch somewhat.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication,
2. The payload parameter is optional. A notifying client can either call
NOTIFY foo; or NOTIFY foo 'payload';. The length of the payload is
currently limited to 128 characters... Not sure if we should allow longer
payload strings...
Might be a good idea to make the max the same as the max
On ons, 2009-11-11 at 19:45 -0500, Tom Lane wrote:
try
insert
catch unique_constraint_violation
update
end try
this will end up cluttering the logs with all the constraint violation
messages.
Really? It's not supposed to.
There might be a different bug here. This
On Thu, Nov 12, 2009 at 8:25 AM, Andrew Chernow a...@esilo.com wrote:
2. The payload parameter is optional. A notifying client can either call
NOTIFY foo; or NOTIFY foo 'payload';. The length of the payload is
currently limited to 128 characters... Not sure if we should allow
longer
payload
Peter Eisentraut pete...@gmx.net writes:
There might be a different bug here. This doesn't look right:
The UPDATE lacks a WHERE clause :-(
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Fujii Masao masao.fu...@gmail.com writes:
The problem is that fsync needs to be issued too frequently, which would
be harmless in asynchronous replication, but not in synchronous one.
A transaction would have to wait for the primary's and standby's fsync
before returning a success to a client.
Andrew Gierth and...@tao11.riddles.org.uk writes:
A followup question: currently the code uses the datum interface for
tuplesort. Obviously with multiple columns the slot interface is used
instead; but is there any performance advantage for staying with the
datum interface for the
What advantage is there in limiting it to a tiny size? This is a
'payload' after all...an arbitrary data block. Looking at the patch I
noticed the payload structure (AsyncQueueEntry) is fixed length and
designed to lay into QUEUE_PAGESIZE (set to) BLCKSZ sized pages.
H. Looks like the
On Fri, Nov 06, 2009 at 09:53:20PM -0500, Andrew Dunstan wrote:
Joshua Tolley wrote:
I looked through the
regression tests and didn't find any that used plperl -- should we add one
for
this (or for this and all kinds of other stuff)? Is there some way to make
running the regression test
On ons, 2009-11-04 at 16:02 +0200, Peter Eisentraut wrote:
Here is a patch to support arrays in PL/Python as parameters and
return values.
Slightly updated version with fixed reference counting.
diff --git a/src/pl/plpython/expected/plpython_types.out
On Thu, Nov 12, 2009 at 3:09 PM, Andrew Chernow a...@esilo.com wrote:
What advantage is there in limiting it to a tiny size? This is a
'payload' after all...an arbitrary data block. Looking at the patch I
noticed the payload structure (AsyncQueueEntry) is fixed length and
designed to lay
Folks,
Here's expected behavior:
davidfet...@postgres=# SELECT array(values(1),(null));
?column?
──
{1,NULL}
(1 row)
The next one is just plain unexpected. Either it's a bug, or it needs
more documentation in the function description in the docs, \df+
output, etc.
On Thu, Nov 12, 2009 at 3:30 PM, Merlin Moncure mmonc...@gmail.com wrote:
Couple of questions:
*) is BLCKSZ a hard requirement, that is, coming from the slru
implementation, or can QUEUE_PAGESIZE be bumped independently of block
size.
It's the size of slru's pages.
*) why not make the
So I think we're agreed on adding a variable_conflict GUC for plpgsql.
The straight-and-narrow way to do it would be to make this a custom
GUC that's defined only when plpgsql is dynamically loaded into the
backend. However that implies a lot of notational overhead, notably
having to put plpgsql
--On 12. November 2009 15:48:44 + Greg Stark gsst...@mit.edu wrote:
I'm beginning to think the right solution is to reject the idea of
adding a payload to the NOTIFY mechanism and instead provide a queue
contrib module which provides the interface people want.
Isn't PgQ already the
David Fetter da...@fetter.org writes:
The next one is just plain unexpected.
array_to_string ignores null elements. What do you think it should do
with them?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Thu, Nov 12, 2009 at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
One reason to argue for the other way is that maybe it wouldn't only
be consulted by plpgsql. In particular I can easily imagine SQL
functions having the same issue as soon as someone gets around to
letting them use names
On Thu, Nov 12, 2009 at 11:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
However I share Greg's concerns that people are trying to use NOTIFY
as a message queue which it is not designed to be.
Yes. Particularly those complaining that they want to have
On Thu, Nov 12, 2009 at 11:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
However I share Greg's concerns that people are trying to use NOTIFY
as a message queue which it is not designed to be.
Yes. Particularly those complaining that they want to have
On Thu, Nov 12, 2009 at 11:39 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Nov 12, 2009 at 11:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
However I share Greg's concerns that people are trying to use NOTIFY
as a message queue which it is not
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 12, 2009 at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
One reason to argue for the other way is that maybe it wouldn't only
be consulted by plpgsql. In particular I can easily imagine SQL
functions having the same issue as soon as
On Thu, 2009-11-12 at 06:46 -0500, Robert Haas wrote:
Having said that,
I'm not capable of single-handedly effecting an on-time release
You're bloody good and the task needs to fit our capability anyway.
So, yes, you are.
We need larger, more robust pools of
committers, reviewers,
On Thu, Nov 12, 2009 at 11:31 AM, Simon Riggs si...@2ndquadrant.com wrote:
Not a new idea, but I think we should require all patch submitters to do
one review per submission. There needs to be a balance between time
spent on review and time spent on dev. The only real way this happens in
any
Now you might say that yeah, that's the point, we're trying to enable
using NOTIFY in a different style. The problem is that if you are
trying to use NOTIFY as a queue, you will soon realize that it has
the wrong semantics for that --- in particular, losing notifies across
a system crash or
On Thu, Nov 12, 2009 at 4:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So while a payload string for NOTIFY has been on the to-do list since
forever, I have to think that Greg's got a good point questioning
whether it is actually a good idea.
Here's an example of why I'd like a payload (and not
Joachim Wieland j...@mcknight.de writes:
However I share Greg's concerns that people are trying to use NOTIFY
as a message queue which it is not designed to be.
Yes. Particularly those complaining that they want to have very large
payload strings --- that's pretty much a dead giveaway that
On Wed, Nov 11, 2009 at 2:03 PM, Josh Berkus j...@agliodbs.com wrote:
I'd be happy to get together at some pre-appointed hour this weekend
(Saturday / Sunday) to talk it over by phone / IRC. PDXPUG was already
planning to get together to review some patches this Sunday from 3-5pm
PST, so that
However I share Greg's concerns that people are trying to use NOTIFY
as a message queue which it is not designed to be.
When you have an established libpq connection waiting for notifies it is
not unreasonable to expect/desire a payload. ISTM, the problem is that
the initial design was
On Thu, Nov 12, 2009 at 8:31 AM, Simon Riggs si...@2ndquadrant.com wrote:
Not a new idea, but I think we should require all patch submitters to do
one review per submission. There needs to be a balance between time
spent on review and time spent on dev. The only real way this happens in
any
Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
The problem is that fsync needs to be issued too frequently, which would
be harmless in asynchronous replication, but not in synchronous one.
A transaction would have to wait for the primary's and standby's fsync
before returning a
In a few days the 3rd 8.5 development CommitFest, 2009-11, is going to
kick off, with the end goal being an alpha3 prerelease. If you have a
patch in progress, you'll need to submit it before the deadline of
2009-11-15 00:00:00 GMT for it to be considered during this round:
Simon Riggs escreveu:
So, I
propose that we simply ignore patches from developers until they have
done sufficient review to be allowed to develop again.
Is it really impolite for a first-contributor, no?
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers
On Thu, Nov 12, 2009 at 11:20:26AM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
The next one is just plain unexpected.
array_to_string ignores null elements. What do you think it should
do with them?
It should concatenate them, i.e. return a NULL if the array includes
any
On 11/12/09 9:45 AM, Greg Smith wrote:
For lack of a more qualified volunteer, I'll be handling the initial
round of patch assignments and reviewer organization.
Hmmm? Who's more qualified than you, exactly?
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
That's basically just it: Assume bashing is part of the process. Don't
think of it as bashing. Take the constructive criticism from it, ignore
the rest. Assume only one out of three feature ideas will make it.
Apply the prerequisite amount of gamesmanship to the system and tune
your
Tom Lane wrote:
David Fetter da...@fetter.org writes:
The next one is just plain unexpected.
array_to_string ignores null elements. What do you think it should do
with them?
regards, tom lane
This seems somewhat related to the long-running discussion from
I like this idea. Perhaps also if a person is reviewing a patch for
the first time, we could make some effort to get a more experienced
person paired up with them.
When I was CFM last year, I assigned patches for review first if the
patch author was doing a review themselves. Patches whose
On Thu, Nov 12, 2009 at 1:25 PM, Albert Cervera i Areny
alb...@nan-tic.com wrote:
A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure:
Simon Riggs escreveu:
So, I
propose that we simply ignore patches from developers until they have
done sufficient review to be allowed
A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure:
Simon Riggs escreveu:
So, I
propose that we simply ignore patches from developers until they have
done sufficient review to be allowed to develop again.
Is it really impolite for a first-contributor, no?
I don't
On Thu, Nov 12, 2009 at 1:28 PM, Steve Crawford
scrawf...@pinpointresearch.com wrote:
Although it might cause a fair amount of backward-compatibility trouble, the
string representation could either use NULL to represent a null element as
is allowed in other contexts or require that empty-string
2009/11/13 Euler Taveira de Oliveira eu...@timbira.com:
Simon Riggs escreveu:
So, I
propose that we simply ignore patches from developers until they have
done sufficient review to be allowed to develop again.
Is it really impolite for a first-contributor, no?
I support Simon's proposal,
On Thu, Nov 12, 2009 at 11:40 AM, Merlin Moncure mmonc...@gmail.com wrote:
I'm sorry, the 128 character limit is simply lame (other than for
unsolvable implementation/performance complexity which I doubt is the
case here), and if that constraint is put in by the implementation,
than the
On Thu, 2009-11-12 at 15:52 -0200, Euler Taveira de Oliveira wrote:
Simon Riggs escreveu:
So, I
propose that we simply ignore patches from developers until they have
done sufficient review to be allowed to develop again.
Is it really impolite for a first-contributor, no?
I believe the
Robert Haas escribió:
On Thu, Nov 12, 2009 at 1:25 PM, Albert Cervera i Areny
alb...@nan-tic.com wrote:
A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure:
Simon Riggs escreveu:
So, I
propose that we simply ignore patches from developers until they have
done
I wrote:
Fair enough. I'll start writing the custom GUC then.
While testing that, I noticed a pre-existing GUC limitation that maybe
we should do something about now: it does not work very nicely for
custom SUSET GUC variables. Normally, if a variable is SUSET, an
ordinary user can't do ALTER
On Thu, Nov 12, 2009 at 01:33:41PM -0500, Robert Haas wrote:
On Thu, Nov 12, 2009 at 1:28 PM, Steve Crawford
scrawf...@pinpointresearch.com wrote:
Although it might cause a fair amount of backward-compatibility
trouble, the string representation could either use NULL to
represent a null
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 12, 2009 at 1:28 PM, Steve Crawford
scrawf...@pinpointresearch.com wrote:
Although it might cause a fair amount of backward-compatibility trouble, the
string representation could either use NULL to represent a null element as
is allowed in
On Thu, 2009-11-12 at 11:36 -0500, Robert Haas wrote:
I agree. I would quibble only with the details. I think we should
require patch authors to act as a reviewer for any CommitFest for
which they have submitted patches. We don't need every patch author
to review as many patches as they
On Thu, Nov 12, 2009 at 1:27 PM, Josh Berkus j...@agliodbs.com wrote:
That's basically just it: Assume bashing is part of the process. Don't
think of it as bashing. Take the constructive criticism from it, ignore
the rest. Assume only one out of three feature ideas will make it.
Apply the
--On 4. November 2009 09:57:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
I think the
consensus was that the way to fix this (along with some other problems)
is to start representing NOT NULL constraints in pg_constraint, turning
attnotnull into just a bit of denormalization for performance.
Josh Berkus wrote:
On 11/12/09 9:45 AM, Greg Smith wrote:
For lack of a more qualified volunteer, I'll be handling the initial
round of patch assignments and reviewer organization.
Hmmm? Who's more qualified than you, exactly?
I was alluding to the fact that Robert isn't
I'm not addressing the complaints Emmanuel has about patch submission,
but was inspired by what he said. I hesitated to post this to
-hackers, but my hope is that my comments are taken in the spirit of
reflection.
I've been thinking about the Postgres community and things that
differentiate it
Hi
While trying to create a domain over an array type to enforce a certain
shape or certain contents of an array (like the array being only
one-dimensional or not containing NULLs), I've stumbled over what I
believe to be a bug in postgresql 8.4
It seems that check constraints on domains are
Greg Smith g...@2ndquadrant.com writes:
The set of patches I have the least feel for are the five ECPG
submissions, some of which were reviewed already. I would particularly
appreciate any early information reviewers might provide about their
capability/willingness to work on that set.
Hello Everyone,
I recently spent some time comparing the various techniques used to
backup/export MySQL, SQLite, and PostgreSQL databases. So far, pg_dump
is the best tool I've used. I was well pleased with its efficient
syntax and functionality. However, I have two feature requests that I
On Thu, Nov 12, 2009 at 1:45 PM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2009-11-12 at 11:36 -0500, Robert Haas wrote:
I agree. I would quibble only with the details. I think we should
require patch authors to act as a reviewer for any CommitFest for
which they have submitted patches.
On Nov 12, 2009, at 10:46 AM, David Fetter wrote:
My question boils down to, why is this string concatenation different
from all other string concatenations?
Does it have something to do with afikoman?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Boszormenyi Zoltan escribió:
Alvaro Herrera írta:
I have applied this patch after some tinkering. I mainly added support
for fetch_args: FORWARD opt_from_in name and BACKWARD opt_from_in
name in ecpg.addons which apparently you forgot.
Thanks. Your fix is correct if this patch is
Tom Lane wrote:
Greg Smith g...@2ndquadrant.com writes:
The set of patches I have the least feel for are the five ECPG
submissions, some of which were reviewed already. I would particularly
appreciate any early information reviewers might provide about their
capability/willingness to
On Thu, Nov 12, 2009 at 11:46:54AM -0800, David Wheeler wrote:
On Nov 12, 2009, at 10:46 AM, David Fetter wrote:
My question boils down to, why is this string concatenation
different from all other string concatenations?
Does it have something to do with afikoman?
I was wondering who'd
Here's the patch to support Python =3.1 with PL/Python. The
compatibility code is mostly in line with the usual 2-3 C porting
practice and is documented inline.
I needed to create an arguably weird hack to manage the regression
tests. Instead of creating a new expected file for pretty much
Robert Haas escribió:
I used to feel this way, too. I'm not sure whether it's really worse
at first, or whether it just seems worse a first until you get used to
it. There is no getting around the fact that this is a community of
very smart people. I work at a company where I'm the only
On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:
The same goes for other OSS projects. There's quite a few random OSS
apps which were created on PG 7.4 and have never offered their users an
upgrade path (Gnuworld comes to mind). They need an EOL announcement to
get them motivated to
On Thu, Nov 12, 2009 at 2:49 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Boszormenyi Zoltan escribió:
Alvaro Herrera írta:
I have applied this patch after some tinkering. I mainly added support
for fetch_args: FORWARD opt_from_in name and BACKWARD opt_from_in
name in ecpg.addons
On Thu, 2009-11-12 at 14:43 -0500, Robert Haas wrote:
Not all contributors are fluent English readers and writers.
I certainly do not discourage those people from reviewing, but I can
understand how it might be more frustrating and less productive for
them. An important part of review is
Andreas 'ads' Scherbaum wrote:
On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:
The same goes for other OSS projects. There's quite a few random OSS
apps which were created on PG 7.4 and have never offered their users an
upgrade path (Gnuworld comes to mind). They need an EOL
I think that's the key argument here. We have several customers, which
need a very careful and time consuming evaluation before they can go
into production with a new platform, which is quite time consuming and
needs significant preparation for them. Announcing an EOL early in time
would
consistently fails when compiled on ubuntu 9.10 here (on mini 10v).
regression.diffs.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
Bernd Helmle maili...@oopsware.de writes:
My first idea is to just introduce a special contype in pg_constraint
representing a NOT NULL constraint on a column, which holds all required
information to do the mentioned maintenance stuff on them and to keep most
of the current infrastructure.
Peter Eisentraut pete...@gmx.net writes:
Here's the patch to support Python =3.1 with PL/Python. The
compatibility code is mostly in line with the usual 2-3 C porting
practice and is documented inline.
There was considerable debate earlier about whether we wanted to treat
Python 3 as a
On Thu, Nov 12, 2009 at 3:12 PM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2009-11-12 at 14:43 -0500, Robert Haas wrote:
Not all contributors are fluent English readers and writers.
I certainly do not discourage those people from reviewing, but I can
understand how it might be more
Grzegorz Jaskiewicz wrote:
consistently fails when compiled on ubuntu 9.10 here (on mini 10v).
+ ERROR: incompatible library
/home/kgrittn/postgresql-8.4.0/src/test/regress/refint.so: version
mismatch
+ DETAIL: Server is version 8.4, library is version 8.3.
You might take this as
Grzegorz Jaskiewicz g...@pointblue.com.pl writes:
consistently fails when compiled on ubuntu 9.10 here (on mini 10v).
Locale issue maybe? Looks like it has some odd ideas about text
sort order.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
AFAIK the ecpg patches are all waiting on Michael Meskes to have time
to review/commit them. ecpg is pretty much his turf and no other
committers are likely to touch these patches.
Great to know, and since some of the regular reviewers already made a
pass through them there's
Mark Hammonds mhammo...@omniti.com writes:
1. View Based Exports
In addition to being able to dump specific tables, it seems useful to
be able to quickly specify and dump entire views.
Isn't this pretty much the same thing as your #2? A view in PG isn't
materialized, it's nothing but a
On Thu, 12 Nov 2009 15:23:06 -0500 Andrew Dunstan wrote:
Andreas 'ads' Scherbaum wrote:
On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:
The same goes for other OSS projects. There's quite a few random OSS
apps which were created on PG 7.4 and have never offered their users an
Tom Lane escribió:
I wrote:
Fair enough. I'll start writing the custom GUC then.
While testing that, I noticed [...]
With all this fallout, I think it would be cleaner to step back and make
it a regular GUC variable, not custom. Pretending that plpgsql is
somehow not an integral part of
On Thu, 2009-11-12 at 23:09 +0100, Andreas 'ads' Scherbaum wrote:
On Thu, 12 Nov 2009 15:23:06 -0500 Andrew Dunstan wrote:
Andreas 'ads' Scherbaum wrote:
On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:
The same goes for other OSS projects. There's quite a few random OSS
Alvaro Herrera alvhe...@commandprompt.com writes:
With all this fallout, I think it would be cleaner to step back and make
it a regular GUC variable, not custom. Pretending that plpgsql is
somehow not an integral part of the system is not completely true
anyway. Yes, we're playing favorites
On Thu, Nov 12, 2009 at 13:55, Tom Lane t...@sss.pgh.pa.us wrote:
I'd go for the first of those, for sure. Testing attnotnull is
significantly cheaper than enforcing a generic constraint expression,
and NOT NULL is a sufficiently common case to be worth worrying about
optimizing it.
When I
On the subject topic, I have to say that I don't see where Robert
hasn't met the qualifications mentioned so far on this thread as
required to promote someone to the committer level; are there some
requirements which exist but haven't been mentioned?
Regarding the specific issues below, which
Alex Hunsaker bada...@gmail.com writes:
On Thu, Nov 12, 2009 at 13:55, Tom Lane t...@sss.pgh.pa.us wrote:
I'd go for the first of those, for sure. Â Testing attnotnull is
significantly cheaper than enforcing a generic constraint expression,
and NOT NULL is a sufficiently common case to be
Pavel Stehule escribió:
Hello
actualised version: enhance check inside sql function
What is this against? It has a few suspicious chunks, such as
***
*** 358,364
funcexpr-funcid = funcid;
funcexpr-funcresulttype = rettype;
!
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
needs significant preparation for them. Announcing an EOL early in time
would give them the required time before the version used disappears.
So, should we announce it for June?
No, it should be longer. June is practically around the
1 - 100 of 150 matches
Mail list logo
