Bruce Momjian wrote:
I removed your use of the pg_auth flat file. By the time you have the
PROC entry to do your lookups, you might as well just use the system
cache.
There is a race condition in the code because we set our PROC entry
before we check for other entries. If there is one connect
Petr Jelinek wrote:
> Bruce Momjian wrote:
>
> >I removed your use of the pg_auth flat file. By the time you have the
> >PROC entry to do your lookups, you might as well just use the system
> >cache.
> >
> >There is a race condition in the code because we set our PROC entry
> >before we check for
Patch applied. Thanks.
---
Alvaro Herrera wrote:
> I've had this small patch in my local tree for a while. It documents
> new commands which may make an SPI call fail.
>
> --
> Alvaro Herrera ()
> Maybe there's lots of
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Ma
Bernd Helmle wrote:
> --On Donnerstag, Juli 28, 2005 23:12:37 -0400 Bruce Momjian
> wrote:
>
> > Here is an updated version of your patch. Would you supply SGML
> > documentation updates to match the code changes? Thanks.
>
> Bruce, is there any requirement to add some regression tests, too?
--On Donnerstag, Juli 28, 2005 23:12:37 -0400 Bruce Momjian
wrote:
Here is an updated version of your patch. Would you supply SGML
documentation updates to match the code changes? Thanks.
Bruce, is there any requirement to add some regression tests, too?
--
Bernd
---
Patch applied. Thanks. /contrib/dbsize removed. New functions:
pg_tablespace_size
pg_database_size
pg_relation_size
pg_complete_relation_size
pg_size_pretty
---
Dave Page wrote:
>
Is this the functionality we agreed we wanted?
---
Oliver Jowett wrote:
> Bruce Momjian wrote:
> > Is this patch being worked on?
>
> Here's an updated version. It compiles and appears to work as expected
> under Linux (sup
BTW, is there still any reason not to remove the contrib/pg_autovacuum
directory from CVS?
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/f
Patch applied. Thanks. reindexdb removed from /contrib.
---
Euler Taveira de Oliveira wrote:
> Hi,
>
> Sorry for the delay. I'm too busy the last days. Based in the
> discussions [1], here is a patch that translate the r
I am waiting for pg_dump support for this patch.
---
Satoshi Nagayasu wrote:
> Bruce Momjian wrote:
> > I am not sure what to do with this patch. It is missing dump
> > capability, there is no clause to disable all triggers
Simon Riggs wrote:
> On Sat, 2005-05-21 at 18:38 +0100, Simon Riggs wrote:
> > On Fri, 2005-05-20 at 23:16 -0400, Bruce Momjian wrote:
> > > Any farther on this?
> >
> > No, but it will be in by deadline.
> >
> > I need to make first base with partitioning before I can do this. Hence
> > my (othe
On Fri, Jul 29, 2005 at 11:19:34AM -0400, Tom Lane wrote:
> BTW, is there still any reason not to remove the contrib/pg_autovacuum
> directory from CVS?
I still haven't added custom cost-based delays, but I don't see that as
a showstopper for removing it. I just went through the CVS log and I
don
Hackers,
Subject says it all. Please review the grammar ...
--
Alvaro Herrera ()
"Et put se mouve" (Galileo Galilei)
Index: ref/vacuum.sgml
===
RCS file: /home/alvherre/cvs/pgsql/doc/src/sgml/ref/vacuum.sgml,v
retrieving revision 1
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Updated this patch:
> - The stat collector is modified so as to keep shared relations separate
> from regular ones. Autovacuum understands this.
> [etc]
Applied with some fixes --- you had broken the reporting of statistics
for shared tables, for o
On Fri, Jul 29, 2005 at 03:33:09PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Updated this patch:
> > - The stat collector is modified so as to keep shared relations separate
> > from regular ones. Autovacuum understands this.
> > [etc]
>
> Applied with some fixes
This patch implements an optional EXACT keyword after the INTO keyword
of the PL/pgSQL SELECT INTO command. The motivation is to come closer
to Oracle's SELECT INTO behavior: when SELECTing INTO scalar targets,
raise an exception and leave the targets untouched if the query does not
return exactly
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Also the patch seemed to be missing diffs for header files?
> Damn, I generated the diff from within src/backend instead of the root
> :-( Sorry for the inconvenience.
No problem --- reverse-engineering the changes to function declarations
was simple
Matt Miller <[EMAIL PROTECTED]> writes:
> This patch implements an optional EXACT keyword after the INTO keyword
> of the PL/pgSQL SELECT INTO command. The motivation is to come closer
> to Oracle's SELECT INTO behavior: when SELECTing INTO scalar targets,
> raise an exception and leave the target
On 7/29/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Matt Miller <[EMAIL PROTECTED]> writes:
> > This patch implements an optional EXACT keyword after the INTO keyword
> > of the PL/pgSQL SELECT INTO command. The motivation is to come closer
> > to Oracle's SELECT INTO behavior: when SELECTing INTO s
On Fri, Jul 29, 2005 at 05:46:11PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >> Also the patch seemed to be missing diffs for header files?
>
> > Damn, I generated the diff from within src/backend instead of the root
> > :-( Sorry for the inconvenience.
>
> No problem
On Fri, 2005-07-29 at 17:52 -0400, Tom Lane wrote:
> Matt Miller <[EMAIL PROTECTED]> writes:
> > The motivation is to come closer to Oracle's SELECT INTO
> > behavior: when SELECTing INTO scalar targets,
> > raise an exception and leave the targets untouched if the query does
> > not return exactly
> > The motivation is to come closer
> > to Oracle's SELECT INTO behavior: when SELECTing INTO scalar targets,
> > raise an exception and leave the targets untouched if the query does not
> > return exactly one row.
> why that is not the default behavior of the SELECT INTO?
> ...
> i mean, when yo
Are you still working on completing this?
---
[EMAIL PROTECTED] wrote:
> Hi there,
>
> Attached is a patch (by Gavin Sherry, fixed up to apply to 8.1 by me) that
> implements INSERT ... RETURNING functionality.
>
> It does
Here here on this one.
With the deprecation of oids on the horizon insert returning is to be
extremely important. It's use with the uniqueidentifier mod would be really
really helpful.
On a similar note, is anyone working on the ability to have a column default
as the product of a function o
Patch applied to 8.0.X and HEAD. Thanks.
---
Chris Browne wrote:
> I believe this change will apply equally to 7.4, 8.0, and CVS HEAD.
>
> Index: FAQ_AIX
>
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Matt Miller wrote:
> This patch implements an optional EXACT keyword after the INTO keyword
> of the PL/pgSQL SELECT
Sorry, patch removed from the queue. I now see the later discussion.
---
Matt Miller wrote:
> This patch implements an optional EXACT keyword after the INTO keyword
> of the PL/pgSQL SELECT INTO command. The motivation is
Bruce Momjian wrote:
> Is this the functionality we agreed we wanted?
I think it covers Tom's comments on the first version:
- a GUC to turn off SO_KEEPALIVE isn't particularly useful
- don't do redundant get/setsockopt calls on backend startup
-O
---(end of broadcast)
On Fri, Jul 29, 2005 at 11:24:37PM -0400, Bruce Momjian wrote:
>
> Would someone who knows perl update plperl.sgml and send me a patch?
>
> Also, is this still true in 8.1:
>
> In the current implementation, if you are fetching or returning
> very large data sets, you should be aware
30 matches
Mail list logo
