Michael Glaesemann <[EMAIL PROTECTED]> writes:
> 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.
> If I'm reading my dr
[ catching up on today's email ]
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> In the first place, it is considered bad form for a package to install
>> an absolute symlink to /usr/share/zoneinfo:
> Fwiw Debian also faced this issue and came to a different
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.
It's not equivalent to GROUP BY "foo"
test=# select record_id as foo
On Aug 22, 2007, at 20:36 , Ben Tilly wrote:
On 8/22/07, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
On Aug 22, 2007, at 18:45 , Ben Tilly wrote:
1. Just a minor annoyance, but why must subqueries in FROM clauses
have an alias?
It's required by the SQL standard, AIUI. I wonder what Ente
Ben Tilly wrote:
On 8/22/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
"Ben Tilly" <[EMAIL PROTECTED]> writes:
2. Why is 'non-integer constant in GROUP BY' an error?
Hm... I was a bit surprised by this warning myself. IIRC there was an
implementation convenience issue.
If your implementation
On 8/22/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> "Ben Tilly" <[EMAIL PROTECTED]> writes:
>
> > Hopefully this is the right place for a few feature requests that
> > would address some of the things that I've noticed in postgres.
> >
> > 1. Just a minor annoyance, but why must subqueries in
On 8/22/07, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
>
> On Aug 22, 2007, at 18:45 , Ben Tilly wrote:
>
> > 1. Just a minor annoyance, but why must subqueries in FROM clauses
> > have an alias?
>
> It's required by the SQL standard, AIUI. I wonder what EnterpriseDB
> does?
I can well believe
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> Why would --with-zoneinfo want to use a symlink though? Shouldn't it
>> just compile the binary to use the path specified directly?
> The way this question is posed appears to imply that doing the latter is
> easier, but it's
"Ben Tilly" <[EMAIL PROTECTED]> writes:
> Hopefully this is the right place for a few feature requests that
> would address some of the things that I've noticed in postgres.
>
> 1. Just a minor annoyance, but why must subqueries in FROM clauses
> have an alias? For instance suppose that I have a
On Aug 22, 2007, at 18:45 , Ben Tilly wrote:
1. Just a minor annoyance, but why must subqueries in FROM clauses
have an alias?
It's required by the SQL standard, AIUI. I wonder what EnterpriseDB
does?
2. Why is 'non-integer constant in GROUP BY' an error?
This works for now:
case
Ben,
pgsql-sql is probably the appropriate list for future queries of this
nature.
Note that the below is my personal opinion; each PG developer has their
own.
> 1. Just a minor annoyance, but why must subqueries in FROM clauses
> have an alias? For instance suppose that I have an orders tabl
Gregory Stark wrote:
> Why would --with-zoneinfo want to use a symlink though? Shouldn't it
> just compile the binary to use the path specified directly?
The way this question is posed appears to imply that doing the latter is
easier, but it's not. If someone wants to do the extra work, maybe
t
Tom Lane wrote:
> Red Hat distributions, at least, will never be able to use it in the
> given form.
This just encoded what a packager would presumably have done anyway. If
it's not going to work for Red Hat, then it's never going to work for
Red Hat in any way without major reeingineering (suc
Hopefully this is the right place for a few feature requests that
would address some of the things that I've noticed in postgres.
1. Just a minor annoyance, but why must subqueries in FROM clauses
have an alias? For instance suppose that I have an orders table, and
one of the fields is userid. T
"Tom Lane" <[EMAIL PROTECTED]> writes:
> In the first place, it is considered bad form for a package to install
> an absolute symlink to /usr/share/zoneinfo:
>
> "symlinks _should_ be relative. Even if all they have in common is /."
> - Jeremy Katz
> https://www.redhat.com/archives/fedora-maintai
[EMAIL PROTECTED] (Peter Eisentraut) writes:
> Log Message:
> ---
> Add configure option --with-system-tzdata to use operating system time zone
> database.
While this looked like a reasonable idea in the abstract, it turns out
that it was probably a waste of time. Red Hat distributions, a
Hackers,
We had a massive power outage in the Norway lab. So please ignore any
failures from the Sun/Solaris buildfarm servers for the next 48 hours.
--Josh
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
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 supported automagically.
They are avai
On Wed, 22 Aug 2007, Tom Lane wrote:
I notice that the existing tsearch documentation that we've imported
fairly consistently refers to Snowball dictionaries with names like
"en_stem", "ru_stem", etc. However, CVS HEAD is set up to create them
with names "english", "russian", etc. As I've been
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)--
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> Sounds reasonable, but why exactly did we spell out "english" instead of "en"
> ?
> Seems the abbrev is much easier to extract from LANG or browser prefs ...
Mainly because we're following the upstream snowball project on the
naming.
I d
Merlin Moncure wrote:
> On 8/21/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>> OTOH, if we do it as a compat package, we need to set a firm end-date on
>> it, so we don't have to maintain it forever.
>
> I would suggest making a pgfoundry project...that's what was done with
> userlocks. I
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> The first kluge that comes to mind is to suppress the error check in a
>> standalone backend (ie, when not IsUnderPostmaster), which would cover
>> the initdb case. But maybe there are better answers ... any ideas?
> Don't see, but that's connected onl
Hmm. That's a problem, but I don't think that not having any error
checking on CREATE TEXT SEARCH DICTIONARY's parameters is a good
solution.
Agreed
The first kluge that comes to mind is to suppress the error check in a
standalone backend (ie, when not IsUnderPostmaster), which would cover
th
Sounds reasonable, but why exactly did we spell out "english" instead of "en" ?
Seems the abbrev is much easier to extract from LANG or browser prefs ...
Andreas
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Tom Lane
Gesendet: Mittwoch, 22. A
On Aug 22, 2007, at 11:10 , Tom Lane wrote:
I notice that the existing tsearch documentation that we've imported
fairly consistently refers to Snowball dictionaries with names like
"en_stem", "ru_stem", etc. However, CVS HEAD is set up to create them
with names "english", "russian", etc. As I
Bruce Momjian wrote:
> Tom Lane wrote:
>> "Hamid Quddus Akhtar" <[EMAIL PROTECTED]> writes:
Offhand I'd say that an empty file is a legitimate corner case,
so we should just take it silently.
>>> Shouldn't we be warning about an empty file rather than just swallowing
>>> up the error?
>>
I notice that the existing tsearch documentation that we've imported
fairly consistently refers to Snowball dictionaries with names like
"en_stem", "ru_stem", etc. However, CVS HEAD is set up to create them
with names "english", "russian", etc. As I've been absorbing more of
the docs I'm starting
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> I also made these statements verify that the tmplinit method will accept
>> the new settings before they get stored; in the original coding you didn't
>> find out about mistakes until the dictionary got invoked.
> That is source of initdb error with -E
Tom Lane wrote:
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
I don't understand why this ALTER variation is so different from existing=20
ones, but maybe the following syntax can't work:
ALTER TEXT SEARCH DICTIONARY swedish ALTER STOPWORDS SET swedish;
You'd have to repeat the whole command
Tom Lane wrote:
> "Hamid Quddus Akhtar" <[EMAIL PROTECTED]> writes:
> >> Offhand I'd say that an empty file is a legitimate corner case,
> >> so we should just take it silently.
>
> > Shouldn't we be warning about an empty file rather than just swallowing
> > up the error?
>
> You are jumping to
"Hamid Quddus Akhtar" <[EMAIL PROTECTED]> writes:
>> Offhand I'd say that an empty file is a legitimate corner case,
>> so we should just take it silently.
> Shouldn't we be warning about an empty file rather than just swallowing
> up the error?
You are jumping to a conclusion, namely that it is
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> I don't understand why this ALTER variation is so different from existing=20
> ones, but maybe the following syntax can't work:
> ALTER TEXT SEARCH DICTIONARY swedish ALTER STOPWORDS SET swedish;
You'd have to repeat the whole command for each optio
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
I'm not sure if this is a sane way to set up a dictionary, but surely
seg faulting is not the right thing to do. Should we throw an error on
an empty dict file, or should we swallow it without crashing?
Offhand I'd say that
Tom Lane wrote:
Applied, thanks. (Hm, I thought we had some buildfarm machines testing
VPATH builds these days? Guess not ...)
I have switched dungbeetle to use vpath. It's a one line config file
change, and it builds every hour (3 a day for stable banches, remainder
for HEAD) if the
"Tom Lane" <[EMAIL PROTECTED]> writes:
> After starting to document this stuff I'm wondering whether it really
> makes sense to change the parser associated with a tsearch
> configuration. The problem is that the new parser might have an
> unrelated set of token types, but we don't do anything ab
Le mardi 21 août 2007, Oleg Bartunov a écrit :
> On Mon, 20 Aug 2007, Tom Lane wrote:
> > I've applied version 0.58 of the patch with a lot of further
> > editorializing. I feel fairly confident now in the code that interfaces
>
> Great ! Just checked and most things after trivial changes are work
Hi list,
Le mardi 21 août 2007, Tom Lane a écrit :
> CREATE TEXT SEARCH DICTIONARY swedish (
> TEMPLATE = snowball,
> LANGUAGE = swedish,
> STOPWORDS = swedish
> );
>
> ALTER TEXT SEARCH DICTIONARY swedish (
> STOPWORDS
> );
>
> this dictionary would have LANGUAGE = swedish and no
On 8/14/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> >
> > Doesn't this design completely fail to take index bloat into account?
> > Repairing heap fragmentation does not reduce the need for VACUUM to work
> > on the indexes.
>
> Index bloat is a bit o
39 matches
Mail list logo
