David Fetter wrote:
> On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote:
> > Here is the patches he made against CVS HEAD (as of today).
>
> The git repository should now match this :)
>
> http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=summary
>
> Apparently, it's easiest
On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote:
> Here is the patches he made against CVS HEAD (as of today).
The git repository should now match this :)
http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=summary
Apparently, it's easiest to clone via the following URL:
ht
Pavan, Heikki,
Is it OK now or do you have any comments?
Thanks Zdenek
Zdenek Kotala napsal(a):
Pavan Deolasee napsal(a):
On Fri, Jul 4, 2008 at 4:25 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
No, there's a itemsz = MAXALIGN(itemsz) call before the check against
HashMaxItemSi
Josh Berkus wrote:
Tom,
Indeed. If the Solaris folk feel that getupeercred() is insecure,
they had better explain why their kernel is that broken. This is
entirely unrelated to the known shortcomings of the "ident" IP
protocol.
The Solaris security & kernel folks do, actually. However,
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> I looked this over and it looks good in general.
> May I think that patch passed review and commit it?
I'd still like to take a look.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To
I looked this over and it looks good in general.
May I think that patch passed review and commit it?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list
Josh Berkus wrote:
Tom,
Indeed. If the Solaris folk feel that getupeercred() is insecure,
they had better explain why their kernel is that broken. This is
entirely unrelated to the known shortcomings of the "ident" IP
protocol.
The Solaris security & kernel folks do, actually. Ho
Tom,
> Indeed. If the Solaris folk feel that getupeercred() is insecure,
> they had better explain why their kernel is that broken. This is
> entirely unrelated to the known shortcomings of the "ident" IP
> protocol.
The Solaris security & kernel folks do, actually. However, there's no
questi
On 7/8/08, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Jaime Casanova escribió:
> > On Thu, May 22, 2008 at 1:18 PM, Jaime Casanova <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > The idea of this patch is to avoid the need to make explicit grants on
> > > sequences owned by tables.
> >
> > I've n
Please find attached a patch that adds some missing descriptions for
aggregates, functions and conversions. This will add COMMENTs to the
conversion sql script as well. Most of the descriptions are taken from the
documentation (especially for the statistic functions). I didn't bother
with som
Simon Riggs wrote:
Fix minor bug in pg_standby, noted by Ferenc Felhoffer
Applied, thanks.
I couldn't find a bug report from Ferenc in the archives. Did he contact
you personally?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-patches mailing list (p
Jaime Casanova escribió:
> On Thu, May 22, 2008 at 1:18 PM, Jaime Casanova <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > The idea of this patch is to avoid the need to make explicit grants on
> > sequences owned by tables.
>
> I've noted that the patch i attached is an older version that doesn't
> co
Here is the patches he made against CVS HEAD (as of today).
According to him followings are fixed with the patches:
- fix crush with DISTINCT
- fix creating VIEW
- fix the case when recursion plan has another recursion plan under it
- fix WITH RECURSIVE ...(..) SELECT ...WHERE.. returns wrong res
On Mon, 2008-07-07 at 16:13 +0100, Simon Riggs wrote:
> I notice log_temp_files is a PGC_USERSET parameter, which is out of step
> with our current thinking on who is allowed to initiate logging.
>
> Is there a rationale for this? Or should we set this to PGC_SUSET like
> all the other logging fu
14 matches
Mail list logo
