Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I've already modified your patch a bit ... please send your updated
> patch so I can merge it into mine. However, my changes were also
> relatively minor. Since Tom wants it to be entirely rewritten then
> maybe merging minor fixes to it is a waste of
Euler Taveira de Oliveira wrote:
> Tom Lane escreveu:
>
> > Hmm ... I'd not looked at that patch before, but now that I have I think
> > it's gone pretty seriously off on the overdesigned-and-inefficient end
> > of the spectrum. Turning RelationGetFillFactor and friends from simple
> > macros int
Gregory Stark wrote:
> WITH RECURSIVE Z(IX, IY, CX, CY, X, Y, I) AS (
> SELECT IX, IY, X::float, Y::float, X::float, Y::float, 0
> FROM (select -2.2 + 0.031 * i, i from generate_series(0,101)
> as i) as xgen(x,ix),
> (select -1.5 + 0.031 * i, i
Tom Lane escreveu:
> Hmm ... I'd not looked at that patch before, but now that I have I think
> it's gone pretty seriously off on the overdesigned-and-inefficient end
> of the spectrum. Turning RelationGetFillFactor and friends from simple
> macros into functions that are probably *at least* a th
Alvaro Herrera escreveu:
> The reloptions patch uses three arrays, one for each type of option
> (bool, int, float). I'm wondering if we could use a single array with
> all options, and a union containing the values. The only problem with
> that (AFAICS) is the initialization.
>
I already tried
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Where/why do you need to do that?
> The reloptions patch uses three arrays, one for each type of option
> (bool, int, float). I'm wondering if we could use a single array with
> all options, and a union containing the values. The on
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I mean something like this:
>
> Where/why do you need to do that?
The reloptions patch uses three arrays, one for each type of option
(bool, int, float). I'm wondering if we could use a single array with
all options, and a union c
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I wonder how portable designated initializers are. As far as I can tell
> they were only defined in C99. Can we use them in our source?
I'd vote no. We're still targeting ANSI C (eg, no // comments).
> I mean something like this:
Where/why do you n
On Fri, Nov 21, 2008 at 04:33:16PM -0500, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > David Fetter escribi?:
> > > On Fri, Nov 21, 2008 at 04:11:11PM -0500, Tom Lane wrote:
> >
> > > > This is a cool hack, agreed, but that doesn't make it a useful
> > > > regression test. Whatever value it m
Hi,
I wonder how portable designated initializers are. As far as I can tell
they were only defined in C99. Can we use them in our source? If not,
is there a way to do this in C89?
I mean something like this:
typedef struct foo {
chartype;
union {
int iv
Buildfarm member pika showed an interesting transient failure yesterday:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=pika&dt=2008-11-21%2012:13:06
./pg_regress --inputdir=. --dlpath=. --multibyte=SQL_ASCII
--load-language=plpgsql --no-locale --temp-install=./tmp_check
--top-builddir=../..
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > gmake VERSION=snapshot dist
> > gmake maintainer-clean
>
> That can't be the right script --- the final "maintainer-clean" would
> wipe out all the derived files made by the dist step. Also, it's
> *definitely* not the script being
KaiGai Kohei <[EMAIL PROTECTED]> writes:
> However, I think we have a few issues, and it makes unclear whether
> we can make an agreement in the community.
> The one is a cost of security hooks. They consume a bit more CPU steps
> when a security mechanism is enabled. The other is prevention to ove
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
According to Stefan Kaltenbrunner, who took the time to delve into
developer.pg.org guts, the script used to generate the snapshots looks
like this
/usr/bin/cvs -q export -rREL8_3_STABLE pgsql
cd pgsql
./configure
cd doc/src
gmake pos
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> According to Stefan Kaltenbrunner, who took the time to delve into
> developer.pg.org guts, the script used to generate the snapshots looks
> like this
> /usr/bin/cvs -q export -rREL8_3_STABLE pgsql
> cd pgsql
> ./configure
> cd doc/src
> gmake postgres
Peter Eisentraut wrote:
> On Friday 21 November 2008 23:33:47 Tom Lane wrote:
> > Historically the man.tar.gz files were created manually because there
> > were some manual fixups needed to the generated man files. I'm not sure
> > what vestiges of that still remain --- Peter's generally been the
Pavan Deolasee escribió:
> On Fri, Nov 21, 2008 at 6:59 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> > The malloc was part of the existing code, explained by comments.
>
> Oh I see. But I don't see any explanations for using malloc instead of
> palloc. Not that the current patch is responsible f
KaiGai Kohei wrote:
> > What I am saying is for the default compile, SQL-level ACLs should be
> > possible because, since the ACL field has optional storage, there is no
> > downside to have it be available by default.
>
> I think it is a possible and desirable desicion from the viewpoint of
> sec
On Sat, 2008-11-22 at 15:14 +0530, Pavan Deolasee wrote:
>
> The malloc was part of the existing code, explained by
> comments.
>
>
> Oh I see. But I don't see any explanations for using malloc instead of
> palloc. Not that the current patch is responsible for t
On Friday 21 November 2008 23:33:47 Tom Lane wrote:
> Historically the man.tar.gz files were created manually because there
> were some manual fixups needed to the generated man files. I'm not sure
> what vestiges of that still remain --- Peter's generally been the one to
> take care of it. But w
On Fri, 2008-11-21 at 19:47 +0900, KaiGai Kohei wrote:
> In the result of "pgbench -i -s 10", the "sepostgresql_row_level=true"
> case consumed 152MB of storage, and the "sepostgresql_row_level=false"
> case consumed 148MB of storage.
Sounds good. It may not sound much to you, but it is all good
On Fri, Nov 21, 2008 at 6:59 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
>
> The malloc was part of the existing code, explained by comments.
>
>
Oh I see. But I don't see any explanations for using malloc instead of
palloc. Not that the current patch is responsible for this, I am wondering
why i
On Sat, 2008-11-22 at 03:39 +0900, Fujii Masao wrote:
> Hi, Simon. Thanks for the comment!!
>
> On Sat, Nov 22, 2008 at 2:09 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, 2008-11-20 at 22:41 +0900, Fujii Masao wrote:
> >
> >> In the current Synch Rep patch, the standby cannot catch u
Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
On Fri, Nov 21, 2008 at 09:06:13PM +0100, Zdenek Kotala wrote:
I takes 2.6 second on my laptop. I think it is not so bad.
About 2.0 on my OS/X laptop. Could this be a problem on whatever
architecture/OS/compiler combo you have?
Not
24 matches
Mail list logo
