On Thu, 23 Aug 2007, Tom Lane wrote:
It is doubtless true in a lightly loaded system, but once the kernel is
under any kind of memory pressure I think it's completely wrong.
The fact that so many tests I've done or seen get maximum throughput in
terms of straight TPS with the background write
Greg Smith <[EMAIL PROTECTED]> writes:
> In the interest of closing work on what's officially titled the "Automatic
> adjustment of bgwriter_lru_maxpages" patch, I wanted to summarize where I
> think this is at ...
> 2) Having backends write their own buffers out does not significantly
> degrad
In the interest of closing work on what's officially titled the "Automatic
adjustment of bgwriter_lru_maxpages" patch, I wanted to summarize where I
think this is at, what I'm working on right now, and see if feedback from
that changes how I submit my final attempt for a useful patch in this are
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Yes, path is accepted (if I remember correctly :-). One thing should be
> added and it is default path based on OS.
If the user doesn't know enough to know what the correct path is, he has
no business using the switch at all. So my opinion is "no way a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Florian G. Pflug wrote:
>> knowing *why* the standard committee disallows that syntax -
>> and why everybody except oracle chose to agree with it would be quite
>> interesting.
> ...
> If you believe that, then a table source without any name at all,
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> The really funny thing is that pgsql, mysql and at least sybase
> *explicitly* dissallow the no-alias case.
I knew that pgsql does that, because I made sure it did ;-). But it is
pretty interesting that these other DBMSes also go out of their way t
Manuel Sugawara <[EMAIL PROTECTED]> writes:
> Hi,
>
> I have a simple query that uses digest(data, 'sha1') and consistently
> crashes the backend
The problem is with null arguments:
ciencias=# select digest(null, 'sha1');
el servidor ha cerrado la conexión inesperadamente,
probablemente
Hi,
I have a simple query that uses digest(data, 'sha1') and consistently
crashes the backend (tested in two different machines):
ciencias=# select version();
version
-
Florian G. Pflug wrote:
> knowing *why* the standard committee disallows that syntax -
> and why everybody except oracle chose to agree with it would be quite
> interesting.
Consider that we rightfully disallow
SELECT * FROM tab1, tab1;
because there are two tables with the same name involved.
Gabor Szabo wrote:
Hi,
a few days ago I registered on http://www.pgbuildfarm.org/register.html
to setup my machine in the PGSQL build farm.
I have not seen an e-mail yet.
I wonder if it is because the spam filter of Gmail ate the message or it
is just the summer holidays that requires more pat
On 8/23/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
> Ben Tilly wrote:
> > On 8/22/07, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
> >> On Aug 22, 2007, at 20:49 , Ben Tilly wrote:
> >>
> >>> If your implementation accepts:
> >>>
> >>> group by case when true then 'foo' end
> >> What would
Hi,
a few days ago I registered on http://www.pgbuildfarm.org/register.html
to setup my machine in the PGSQL build farm.
I have not seen an e-mail yet.
I wonder if it is because the spam filter of Gmail ate the message or it
is just the summer holidays that requires more patience?
regards
Gab
Kevin Grittner wrote:
On Thu, Aug 23, 2007 at 3:01 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
The only argument I've
heard that carries much weight with me is that it eases porting from
other DBMS's that allow this. Are there any others besides Oracle?
select *
I have just noticed that we are still accepting data that is invalid for
the server encoding, and in consequence we can produce a dump which we
can't subsequently load. This is a major bug IMNSHO, and needs to be
fixed for 8.3.
Mark, have you made any progress on fixing this? The last mentio
Chuck McDevitt wrote:
Tom, it isn't just a case of "convenience". When we are trying to
convert users from another database (say Oracle for example) to
PostgeSQL, one of the big stumbling blocks that slows down the work is
all the little query changes that people have to make (people who might
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zdenek Kotala wrote:
Peter Eisentraut wrote:
I'm having trouble with the hardcoded 60 second timeout in pg_ctl.
pg_ctl sometimes just times out and there is no way to make it wait a
little longer. I would like to add an opt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zdenek Kotala wrote:
> Peter Eisentraut wrote:
>> I'm having trouble with the hardcoded 60 second timeout in pg_ctl.
>> pg_ctl sometimes just times out and there is no way to make it wait a
>> little longer. I would like to add an option to be able t
>>> On Thu, Aug 23, 2007 at 3:01 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> The only argument I've
> heard that carries much weight with me is that it eases porting from
> other DBMS's that allow this. Are there any others besides Oracle?
> select * from (select
Peter Eisentraut wrote:
Zdenek Kotala wrote:
Let me know if there something what should be adjusted on my patch. I
would like to do it tomorrow, because I will be offline for next two
weeks.
I can try to fit your patch into what's there now, if you'd rather just
start your holiday or whatever
Zdenek Kotala wrote:
> Let me know if there something what should be adjusted on my patch. I
> would like to do it tomorrow, because I will be offline for next two
> weeks.
I can try to fit your patch into what's there now, if you'd rather just
start your holiday or whatever.
--
Peter Eisentrau
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Michael Glaesemann wrote:
>> How about something like gensym?
> It is dangerous to provide a synthetic name; if the standard ever gets
> modified to support alias-less subqueries, they would likely choose a
> different name-generating algorithm, and we
Tom,
> so you don't get to point to them as one that we'd improve
> compatibility with.
Derby & DB2 are also strict.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your
Josh Berkus <[EMAIL PROTECTED]> writes:
> I still don't see it as terrifically useful functionality, given that it's
> just saving you 4 keystrokes ...
Less than that, because the AS is optional. The only argument I've
heard that carries much weight with me is that it eases porting from
other DB
Peter Eisentraut wrote:
I'm having trouble with the hardcoded 60 second timeout in pg_ctl. pg_ctl
sometimes just times out and there is no way to make it wait a little longer.
I would like to add an option to be able to change that, say
pg_ctl -w --timeout=120. Comments?
+1
I played with
Michael Glaesemann wrote:
>
> On Aug 23, 2007, at 14:25 , Tom Lane wrote:
>
>> Josh Berkus <[EMAIL PROTECTED]> writes:
>>> I just don't see the ability to omit the alias in a query with only one
>>> subquery (the only circumstances under which it would be safe to do so)
>>> as
>>> any significant
"Chuck McDevitt" <[EMAIL PROTECTED]> writes:
> Except "group by 1" meaning "group by column 1" is a PostgreSQL extension,
> not a SQL standard feature, if I recall.
Correct. Part of the reason for being conservative about changing here
is that we've got a mix of standard and nonstandard behavior
Tom,
> As long as you take care that the subquery's column names don't match
> any other ones in the query, you don't *need* an alias for it ---
> there'll be no need to qualify the column names. This extends just
> fine to multiple subqueries.
Oh, hmmm. I was thinking this would somehow be mor
On Aug 23, 2007, at 14:25 , Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
I just don't see the ability to omit the alias in a query with
only one
subquery (the only circumstances under which it would be safe to
do so) as
any significant gain in fuctionality.
Why do you think it
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
FWIW, hardwiring plus an environment variable would seem to address all
currently known und unknown requirements, and is not so totally
different from solutions to previous, related problems.
I think we are converging on the recogni
Josh Berkus <[EMAIL PROTECTED]> writes:
> I just don't see the ability to omit the alias in a query with only one
> subquery (the only circumstances under which it would be safe to do so) as
> any significant gain in fuctionality.
Why do you think it'd be restricted to only one subquery?
As lon
Alvaro Herrera wrote:
It would be even better to use --with-system-tzdata=/usr/share/zoneinfo
which enables lookup in the specified dir, hardwired at compile time in
the executable (I'm not aware if the patch already accepts a path
argument -- seems like the only sane choice). No symlink neede
Tom Lane wrote:
I think we've already found out that the opinions *aren't* equal.
So far the score seems to be:
Red Hat: will use relative symlink
Solaris: will use hardwired path in program
Finally, Because my original patch has not been accepted, Solaris also
use relative s
Chuck McDevitt wrote:
PostgreSQL already has a huge amount of
"non-standard" syntax and semantics (perhaps "extensions" is a better
word?).
Everything from non-standard cast operator, non-standard substr,
non-standard trim, non standard group by semantics (allowing simple ints
to mean column nu
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Note, for example, that libc refers to /usr/share/zoneinfo by
>> absolute path.
>
> After reflecting more about this, that's an awfully strong point.
>
> Maybe we should go back to the original patch from Sun --- that is,
> just h
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Florian G. Pflug
> Sent: Thursday, August 23, 2007 11:04 AM
> To: Ben Tilly
> Cc: Michael Glaesemann; Gregory Stark; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] SQL feature req
On Aug 23, 2007, at 12:25 , Ben Tilly wrote:
It is already extended in postgres. For pretty good reasons.
Yes, this particular point is moot. Whether or not the reasons are
good is another thing and a difference of opinion.
I'm not surprised that the window clause section is impenetrabl
> -Original Message-
> From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 23, 2007 10:26 AM
> To: Chuck McDevitt
> Cc: Tom Lane; Gregory Stark; Michael Glaesemann; Ben Tilly; pgsql-
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] SQL feature requests
>
>
>
> Chuck McD
On Thursday 23 August 2007 09:55, Alvaro Herrera wrote:
> > I think the compromise is to instead of generating aliases at all just
> > use an alias like "*Anonymous Subquery*" and add a boolean flag
> > indicating that that range table is anonymous and not a valid target for
> > references. I start
Ben Tilly wrote:
On 8/22/07, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
On Aug 22, 2007, at 20:49 , Ben Tilly wrote:
If your implementation accepts:
group by case when true then 'foo' end
What would that mean? Regardless of whether or not it's accepted, it
should have *some* meaning.
On 8/23/07, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
> On Aug 23, 2007, at 10:47 , Ben Tilly wrote:
[...]
> > Why does it seem like a bug to you?
> >
> > Turn it around, and tell me in what way is its behaviour surprising to
> > someone who knows SQL. You asked to group on something that is t
On 8/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Chuck McDevitt" <[EMAIL PROTECTED]> writes:
> > Tom, it isn't just a case of "convenience". When we are trying to
> > convert users from another database (say Oracle for example) to
> > PostgeSQL, one of the big stumbling blocks that slows down th
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> FWIW, hardwiring plus an environment variable would seem to address all
> currently known und unknown requirements, and is not so totally
> different from solutions to previous, related problems.
I think we are converging on the recognition that Zde
Tom Lane wrote:
> I think we've already found out that the opinions *aren't* equal.
> So far the score seems to be:
> Red Hat: will use relative symlink
> Solaris: will use hardwired path in program
> ???: will use absolute symlink
> Peter's patch supports only the third cas
Gregory Stark escribió:
> I get this about once a day because I frequently type this ad-hoc query and
> always forget to put the alias in the first time:
>
> postgres=# select count(*),n from (select count(*) as n from test group by i)
> group by n;
> ERROR: subquery in FROM must have an alias
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Note, for example, that libc refers to /usr/share/zoneinfo by
> absolute path.
After reflecting more about this, that's an awfully strong point.
Maybe we should go back to the original patch from Sun --- that is,
just have the configure option chang
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> [ shrug... ] This just reinforces my point: if every packager is going
> >> to have his own opinion about how to do it, there's little point in
> >> trying to provide a pre-fab solution.
>
> > Well, there's a po
"Chuck McDevitt" <[EMAIL PROTECTED]> writes:
> Tom, it isn't just a case of "convenience". When we are trying to
> convert users from another database (say Oracle for example) to
> PostgeSQL, one of the big stumbling blocks that slows down the work is
> all the little query changes that people hav
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck McDevitt wrote:
> Tom, it isn't just a case of "convenience". When we are trying to
> convert users from another database (say Oracle for example) to
> PostgeSQL, one of the big stumbling blocks that slows down the work is
> all the little quer
On 8/22/07, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
>
> On Aug 22, 2007, at 20:36 , Ben Tilly wrote:
[...]
> > I can well believe that the standard says that you must accept
> > subqueries with aliases. But does it say you must reject subqueries
> > without aliases? I strongly doubt that.
>
Chuck McDevitt wrote:
Sometimes supporting "de-facto" standards as well as official standards
makes sense.
On that basis we would support huge pieces of stuff that emulates MySQL
too. Or perhaps you'd like us to follow Oracle's treatment of NULL. Who
gets to choose what is the de facto
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> This seems like a particularly petty case compared to a lot of other
>> extensions we do allow.
>
> That's exactly the problem. Most of our other extensions are justified
> by some significant capability gain.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> [ shrug... ] This just reinforces my point: if every packager is going
>> to have his own opinion about how to do it, there's little point in
>> trying to provide a pre-fab solution.
> Well, there's a point if every packager have his
>
> > This seems like a particularly petty case compared to a lot of other
> > extensions we do allow.
>
> That's exactly the problem. Most of our other extensions are
justified
> by some significant capability gain. This isn't --- it provides zero
> new functionality, and the "convenience" fac
On 8/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Ben Tilly" <[EMAIL PROTECTED]> writes:
> > ... But then I need this (possibly
> > empty) list to have a valid group by statement at the end. In Oracle
> > I used to just write it like this:
>
> > SELECT ...
> > GROUP BY $possible_term_1
> >
Gregory Stark escribió:
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark escribió:
> >
> >> The upside is the convenience which after all is the same upside as most of
> >> our spec grammar extensions. Many many programmers are accustomed to
> >> entering
> >> ad-hoc queries of
Gregory Stark <[EMAIL PROTECTED]> writes:
> I highly doubt the spec would ever conflict with allowing the user to elide
> the aliases given that Oracle (and others?) have always allowed this. Moreover
> if it's been 15 years without them adding it surely that argues we can be
> pretty sure they won
On Aug 23, 2007, at 10:47 , Ben Tilly wrote:
On 8/22/07, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
*This* seems like a bug:
test=# select record_id
, count(observation_id) as bar
from observation
group by record_id
, case when true
th
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Gregory Stark escribió:
>
>> The upside is the convenience which after all is the same upside as most of
>> our spec grammar extensions. Many many programmers are accustomed to entering
>> ad-hoc queries of this form and forcing them to enter an alias
"Ben Tilly" <[EMAIL PROTECTED]> writes:
> ... But then I need this (possibly
> empty) list to have a valid group by statement at the end. In Oracle
> I used to just write it like this:
> SELECT ...
> GROUP BY $possible_term_1
> $possible_term_2
> $possible_term_3
> 'end of possibl
On 8/22/07, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
>
> On Aug 22, 2007, at 20:49 , Ben Tilly wrote:
>
> > If your implementation accepts:
> >
> > group by case when true then 'foo' end
>
> What would that mean? Regardless of whether or not it's accepted, it
> should have *some* meaning.
T
Tom Lane wrote:
> Zdenek Kotala <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> AFAICS that just moves the problem to a different place, one where an
> >> admin *can't* fix it without recompiling ...
>
> > Is there real reason why admin should do it? Timezone files are stored in
> > defined
Gregory Stark escribió:
> The upside is the convenience which after all is the same upside as most of
> our spec grammar extensions. Many many programmers are accustomed to entering
> ad-hoc queries of this form and forcing them to enter an alias for no purpose
> is just silly pedanticism from the
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> AFAICS that just moves the problem to a different place, one where an
>> admin *can't* fix it without recompiling ...
> Is there real reason why admin should do it? Timezone files are stored in
> defined location where "all" software
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Between 7.4 and 8.0, the owner's grant options were removed from the
> aclitem display.
Yeah, that was intentional, because the way we were doing it was wrong
and caused behavioral bugs. The owner's grant options have to be
treated as being granted
Here's a snippet of the affix file around that line:
prefixes
flag *A:
. > ALI # alivaltiosihteeri, alihankkija # line 83
I > ALI\-
Just remove the rules with \-, tsearch allows only alpha character here.
ispell works just fine with it.
I found a
Between 7.4 and 8.0, the owner's grant options were removed from the
aclitem display. This was as a side effect of the fixes of bug #1150,
but I can't readily tell anymore for what specific reason this
happened.
The information schema shows obviously inaccurate data now, and it might
be easy
Tom Lane wrote:
[ catching up on today's email ]
Gregory Stark <[EMAIL PROTECTED]> writes:
Why would --with-zoneinfo want to use a symlink though? Shouldn't it just
compile the binary to use the path specified directly?
AFAICS that just moves the problem to a different place, one where an
a
Oleg Bartunov wrote:
> On Wed, 22 Aug 2007, Heikki Linnakangas wrote:
>
>> Is the file format for the ispell dictionary documented somewhere?
>> There's apparently support for an old and a new format, but I can't
>> figure out what the formats are.
>
> ispell, myspell and hunspell formats are sup
Gregory Stark wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
Why would --with-zoneinfo want to use a symlink though? Shouldn't it just
compile the binary to use the path specified directly? Symlinks are fine for a
sysadmin or a packager but if it's going to be supported by Postgres code
direc
"Tom Lane" <[EMAIL PROTECTED]> writes:
> In short, lots of downsides here, and not a whole lot of upside.
I highly doubt the spec would ever conflict with allowing the user to elide
the aliases given that Oracle (and others?) have always allowed this. Moreover
if it's been 15 years without them
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
>> > how much harder can it be to accept:
>> >
>> > group by 'foo'
>
> Presumably you meant group by "foo".
No that's the whole point. He meant the constant string 'foo' not the column
identifier "foo" which certainly should work now.
-
Tom Lane wrote:
> Hardwiring /usr/share/zoneinfo
> into the binary is isomorphic to having it use a symlink defined that
> way, as far as the objections to absolute symlinks go.
That just shows how silly the relative symlink requirement is in the
first place. If setting a symlink and hardcoding
> > how much harder can it be to accept:
> >
> > group by 'foo'
Presumably you meant group by "foo".
Imho pg should accept group by "foo". It could be part of a constant
removal, that also takes burden off the sort.
e.g. in "select x, count(*) from bar where x=5 group by x", x could be
remov
> > If your implementation accepts:
> >
> > group by case when true then 'foo' end
I think he meant: group by case when true then "foo" end
>
> What would that mean? Regardless of whether or not it's accepted, it
> should have *some* meaning.
>
> It's not equivalent to GROUP BY "foo"
Yea,
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Chuck McDevitt
> Sent: Wednesday, August 22, 2007 11:53 PM
> To: Michael Glaesemann; Ben Tilly
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] SQL feature requests
>
> > ---
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Michael Glaesemann
> Sent: Wednesday, August 22, 2007 5:17 PM
> To: Ben Tilly
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] SQL feature requests
>
>
> On Aug 22, 2007, at 1
76 matches
Mail list logo
