Am Donnerstag, 22. Februar 2007 14:33 schrieb Teodor Sigaev:
> \df says only types of arguments, not a meaning.
Only if you don't provide argument names.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 9:
Am Donnerstag, 22. Februar 2007 18:07 schrieb Markus Schiltknecht:
> > I agree so enhancing parser oabout not standard construct isn't good.
>
> Generally? Wow! This would mean PostgreSQL would always lack behind
> other RDBSes, regarding ease of use. Please don't do that!
You are confusing making
On Thursday 25 January 2007 12:51, Oleg Bartunov wrote:
> On Thu, 25 Jan 2007, Nikolay Samokhvalov wrote:
> > On 1/25/07, Teodor Sigaev <[EMAIL PROTECTED]> wrote:
> >> It's should clear enough for now - dump data from old db and load into
> >> new one.
> >> But dump should be without any contrib/ts
>> CREATE TABLE foo (id serial, names text FULLTEXT);
>>
>> Anything more complicated is a waste of cycles.
>>
>> Joshua D. Drake
>
> I agree. Question: what about multilanguage fulltext.
>
> CREATE INDEX foo USING FULLTEXT(bar) [ WITH czech_dictionary ];
> CREATE TABLE foo (id serial, names text
>> CREATE TABLE foo (id serial, names text FULLTEXT);
>>
>> Anything more complicated is a waste of cycles.
>>
>> Joshua D. Drake
>
> I agree. Question: what about multilanguage fulltext.
>
> CREATE INDEX foo USING FULLTEXT(bar) [ WITH czech_dictionary ];
> CREATE TABLE foo (id serial, names tex
I am not talking about stored procedures. I am talking about a very
ugly, counter intuitive syntax above.
Initializing full text should be as simple as:
CREATE INDEX foo USING FULLTEXT(bar);
(or something similar)
Or:
CREATE TABLE foo (id serial, names text FULLTEXT);
Anything more complicat
Pavel Stehule wrote:
>> > And users are constantly complaining that PostgreSQL doesn't have
>> > fulltext indexing capabilities (if they don't know about tsearch2) or
>> > about how hard it is to use tsearch2.
>> >
>> >> SELECT create_fulltext_mapping(cfgname, ARRAY['lex..','..'],
>> >> ARRAY['...'
> And users are constantly complaining that PostgreSQL doesn't have
> fulltext indexing capabilities (if they don't know about tsearch2) or
> about how hard it is to use tsearch2.
>
>> SELECT create_fulltext_mapping(cfgname, ARRAY['lex..','..'],
>> ARRAY['...']) is readable.
>
> Hardly. Because it
>
> And users are constantly complaining that PostgreSQL doesn't have
> fulltext indexing capabilities (if they don't know about tsearch2) or
> about how hard it is to use tsearch2.
>
>> SELECT create_fulltext_mapping(cfgname, ARRAY['lex..','..'],
>> ARRAY['...']) is readable.
>
> Hardly. Becaus
Hi,
Pavel Stehule wrote:
Functions maybe doesn't see efective, but user's cannot learn new syntax.
Are you serious? That argument speaks exactly *for* extending the
grammar. From other databases, users are used to:
CREATE TABLE ... (SQL)
CREATE INDEX ... (SQL)
CREATE FULLTEXT INDEX ... (Tra
Hi,
Andrew Dunstan wrote:
If we are worried about the size of the transition table and keeping it
in cache (see remarks from Tom upthread) then adding more keywords seems
a bad idea, as it will surely expand the table. OTOH, I'd hate to make
that a design criterion.
Yeah, me too. Especiall
CREATE FULLTEXT CONFIGURATION myfts LIKE template_cfg AS DEFAULT;
SELECT add_fulltext_config('myfts', 'template_cfg', True);
That's simple, but what about
CREATE FULLTEXT MAPPING ON cfgname FOR lexemetypename[, ...] WITH
dictname1[, ...];
?
SELECT create_fulltext_mapping(cfgname, '{lex
Teodor Sigaev wrote:
In that proposed syntax, I would drop all "=", ",", "(", and ")".
They don't seem necessary and they are untypical for SQL commands.
I'd compare with CREATE FUNCTION or CREATE SEQUENCE for SQL commands
that do similar things.
I was looking at CREATE TYPE mostly. With re
CREATE FULLTEXT CONFIGURATION myfts LIKE template_cfg AS DEFAULT;
SELECT add_fulltext_config('myfts', 'template_cfg', True);
That's simple, but what about
CREATE FULLTEXT MAPPING ON cfgname FOR lexemetypename[, ...] WITH dictname1[,
...];
?
SELECT create_fulltext_mapping(cfgname, '{lexemetypena
In that proposed syntax, I would drop all "=", ",", "(", and ")". They
don't seem necessary and they are untypical for SQL commands. I'd
compare with CREATE FUNCTION or CREATE SEQUENCE for SQL commands that
do similar things.
I was looking at CREATE TYPE mostly. With removing "=", ",", "(",
Hi,
Peter Eisentraut wrote:
Oleg Bartunov wrote:
It's not so big addition to the gram.y, see a list of commands
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
As we still to still discuss the syntax: is there a proposal for how a
function based syntax would look like?
CREAT
On Thu, 22 Feb 2007, Peter Eisentraut wrote:
Oleg Bartunov wrote:
It's not so big addition to the gram.y, see a list of commands
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
In that proposed syntax, I would drop all "=", ",", "(", and ")". They
don't seem necessary and they
Joshua D. Drake wrote:
> This is like the third time we have been around this problem. The
> syntax is clear and reasonable imo.
But others have differing opinions.
> Can we stop arguing about it and just include? If there are specific
> issues beyond syntax that is one
> thing, but that this poi
Oleg Bartunov wrote:
> It's not so big addition to the gram.y, see a list of commands
> http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
In that proposed syntax, I would drop all "=", ",", "(", and ")". They
don't seem necessary and they are untypical for SQL commands. I'd
compar
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Markus Schiltknecht wrote:
>>> Are there any ongoing efforts to rewrite the parser (i.e. using
>>> another algorithm, like a recursive descent parser)?
>> Why would you want to do that?
> Last, but not least, the C and C++ syntax is basically set
Markus Schiltknecht wrote:
Are there any ongoing efforts to rewrite the parser (i.e. using
another algorithm, like a recursive descent parser)?
Why would you want to do that?
I recall having read something about rewriting the parser. Together with
Tom being worried about parser performance an
Markus Schiltknecht wrote:
Hi,
I recall having read something about rewriting the parser. Together
with Tom being worried about parser performance and knowing GCC has
switched to a hand written parser some time ago, I suspected bison to
be slow. That's why I've asked.
This has little to do
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Markus Schiltknecht wrote:
>> I didn't find hard facts about runtime complexity of LALR,
>> though (pointers are very welcome).
> a) and b) should be O(1). Processing one token pushes at most one state
> onto the stack, so overall no more than N st
Hi,
Florian G. Pflug wrote:
According to http://en.wikipedia.org/wiki/LR_parser processing one
token in any LR(1) parser in the worst case needs to
a) Do a lookup in the action table with the current (state, token) pair
b) Do a lookup in the goto table with a (state, rule) pair.
c) Push one s
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Oleg Bartunov wrote:
> >> It's not so big addition to the gram.y, see a list of commands
> >> http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
>
> > I looked at the diff file and the major change in gram.y is the creatio
Markus Schiltknecht wrote:
Hi,
Tom Lane wrote:
You mean four different object types. I'm not totally clear on bison's
scaling behavior relative to the number of productions
You really want to trade parser performance (which is *very*
implementation specific) for ease of use?
Bison generat
Hi,
Tom Lane wrote:
You mean four different object types. I'm not totally clear on bison's
scaling behavior relative to the number of productions
You really want to trade parser performance (which is *very*
implementation specific) for ease of use?
Bison generates a LALR [1] parser, which
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Oleg Bartunov wrote:
>> It's not so big addition to the gram.y, see a list of commands
>> http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
> I looked at the diff file and the major change in gram.y is the creation
> of a new object type FUL
It's not so big addition to the gram.y, see a list of commands
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
SQL commands make FTS syntax clear and follow tradition to manage
system objects. From the user's side, I'd be very unhappy to configure
FTS, which can be very complex,
Oleg Bartunov wrote:
> On Tue, 20 Feb 2007, Alvaro Herrera wrote:
>
> > Bruce Momjian wrote:
> >>
> >> FYI, I added this to the patches queue because I think we decided
> >> full-text indexing should be in the core. If I am wrong, please let me
> >> know.
> >
> > One of the objections I remember
On Tue, 20 Feb 2007, Alvaro Herrera wrote:
Bruce Momjian wrote:
FYI, I added this to the patches queue because I think we decided
full-text indexing should be in the core. If I am wrong, please let me
know.
One of the objections I remember to this particular implementation was
that configur
Bruce Momjian wrote:
>
> FYI, I added this to the patches queue because I think we decided
> full-text indexing should be in the core. If I am wrong, please let me
> know.
One of the objections I remember to this particular implementation was
that configuration should be done using functions rat
FYI, I added this to the patches queue because I think we decided
full-text indexing should be in the core. If I am wrong, please let me
know.
---
Teodor Sigaev wrote:
> We (Oleg and me) are glad to present tsearch in core
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.
---
Te
Andrew Dunstan wrote:
I am constantly running into this:
Q. Does PostgreSQL have full text indexing?
A. Yes it is in contrib.
Q. But that isn't part of core.
A. *sigh*
Where on the website can I see what "plugins" are included with
PostgreSQL?
Where on the website can I see the Official Post
On Thu, 25 Jan 2007, Nikolay Samokhvalov wrote:
On 1/25/07, Teodor Sigaev <[EMAIL PROTECTED]> wrote:
It's should clear enough for now - dump data from old db and load into new
one.
But dump should be without any contrib/tsearch2 related functions.
Upgrading from 8.1.x to 8.2.x was not tivial
though that we still have the more odd grammar of actually using Tsearch
to query. Although I don't really have a better suggestion without
adding some ungodly obscure operator.
IMHO, best possible solution is 'WHERE table.text_field @ text'.
Operator @ internally makes equivalent of 'to_tsvecto
On 1/25/07, Teodor Sigaev <[EMAIL PROTECTED]> wrote:
It's should clear enough for now - dump data from old db and load into new one.
But dump should be without any contrib/tsearch2 related functions.
Upgrading from 8.1.x to 8.2.x was not tivial because of very trivial
change in API (actually no
Teodor Sigaev wrote:
>> the patch. I'm personally not sold on the need for modifications to the
>> SQL grammar, for example, as opposed to just using a set of SQL-callable
>> functions and some new system catalogs.
>
> SQL grammar isn't changed significantly - just add variants of
> CREATE/DROP/AL
the patch. I'm personally not sold on the need for modifications to the
SQL grammar, for example, as opposed to just using a set of SQL-callable
functions and some new system catalogs.
SQL grammar isn't changed significantly - just add variants of CREATE/DROP/ALTER
/COMMENTS commands. Next, fun
This is a fairly large patch and I would like the chance to review it
before it goes in --- "we'll commit tomorrow" is not exactly a decent
review window.
Not a problem.
One possible argument for this over the contrib version is a saner
approach to dumping and restoring configurations. However
Dawid Kuroczko wrote:
> This is the reason I like 'modules' best. It makes one think that it
> is something maybe part of core, maybe not, but it has been isolated
> into separate entity for maintenance reasons.
On etymological grounds, "modules" would also be my favorite, but the
term "module"
On 1/24/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
Peter Eisentraut wrote:
>> contrib is a horrible misnomer. Can we maybe bite the bullet and call
>> it something else?
> plugins?
How about 'modules' or 'extras' or 'extensions'? :)
standard-plugins might be more informative. I think of th
On Wed, 24 Jan 2007 22:27:10 +0100, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> I wrote:
>> The closest I could find is Oracle Text, the full-text search for
>> Oracle.
>
> Oh, and note that Oracle Text is an "extension" and not included in the
> Oracle database product proper.
>
Same with
On Wed, 24 Jan 2007, Neil Conway wrote:
On Wed, 2007-01-24 at 13:49 -0500, Tom Lane wrote:
2) once we put this in core we are going to be stuck with supporting its
SQL API forever. Are we convinced that this API is the one we want?
I don't recall even having seen any proposal or discussion.
Hi there,
sorry, if I will a bit verbose - just tried to answer to several postings.
On Wed, 24 Jan 2007, Tom Lane wrote:
Teodor Sigaev wrote:
If there aren't objections then we plan commit patch tomorrow or
after tomorrow.
This is a fairly large patch and I would like the chance to review
On Wed, 24 Jan 2007, Martijn van Oosterhout wrote:
> On Wed, Jan 24, 2007 at 09:38:06PM +0100, Stefan Kaltenbrunner wrote:
> > sure that ISP is a bit stupid(especially wrt plpgsql) - but tsearch2 in
> > the current version is actually imposing some additional(often
> > non-trivial) complexity for
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
IIRC Tom's main objection to the previous proposal was that it involved
large grammar changes, which I understand is not now proposed.
No, they're already in there --- the patch seems to have been written
according to that prop
On Wed, Jan 24, 2007 at 09:38:06PM +0100, Stefan Kaltenbrunner wrote:
> sure that ISP is a bit stupid(especially wrt plpgsql) - but tsearch2 in
> the current version is actually imposing some additional(often
> non-trivial) complexity for things like database restores and upgrades
> so I can see an
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> IIRC Tom's main objection to the previous proposal was that it involved
> large grammar changes, which I understand is not now proposed.
No, they're already in there --- the patch seems to have been written
according to that proposal despite the object
Neil Conway wrote:
If people had a problem with integrating tsearch2 in core they should
have said so much earlier.
Peter, Tom and others raised essentially identical objections when this
design was initially proposed. For example:
http://archives.postgresql.org/pgsql-hackers/2006-11/
On Wed, 2007-01-24 at 18:38 -0300, Alvaro Herrera wrote:
> In any case, I agree with Andrew that it would be pretty dumb to reject
> a funded, already written patch.
Well, there are two separate issues: should we include tsearch2 in core,
and what syntax should it use? Changing the syntax would no
Joshua D. Drake wrote:
> Peter Eisentraut wrote:
> > I wrote:
> >> The closest I could find is Oracle Text, the full-text search for
> >> Oracle.
> >
> > Oh, and note that Oracle Text is an "extension" and not included in the
> > Oracle database product proper.
>
> Cool. Then we will have yet an
Peter Eisentraut wrote:
> I wrote:
>> The closest I could find is Oracle Text, the full-text search for
>> Oracle.
>
> Oh, and note that Oracle Text is an "extension" and not included in the
> Oracle database product proper.
Cool. Then we will have yet another reason to claim we are superior.
J
I wrote:
> The closest I could find is Oracle Text, the full-text search for
> Oracle.
Oh, and note that Oracle Text is an "extension" and not included in the
Oracle database product proper.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadca
Stefan Kaltenbrunner wrote:
> I think one can find arguments for both variants - one of the
> question might even be how other databases are doing that and if the
> proposed syntax is resembling one of those or not.
The closest I could find is Oracle Text, the full-text search for
Oracle. Browsi
Peter Eisentraut wrote:
> Stefan Kaltenbrunner wrote:
>> sure that ISP is a bit stupid(especially wrt plpgsql) - but tsearch2
>> in the current version is actually imposing some additional(often
>> non-trivial) complexity for things like database restores and
>> upgrades so I can see an ISP wanting
Stefan Kaltenbrunner wrote:
> sure that ISP is a bit stupid(especially wrt plpgsql) - but tsearch2
> in the current version is actually imposing some additional(often
> non-trivial) complexity for things like database restores and
> upgrades so I can see an ISP wanting to avoid that altogether.
I
Andrew Dunstan wrote:
> Joshua D. Drake wrote:
>> Where on the website can I see what "plugins" are included with
>> PostgreSQL?
YES! That's IMHO a more fundamental problem. The specific
question about Text Search seems more like a symptom. While
I don't mind Text Search in core, it seems an ev
Peter Eisentraut wrote:
> Jeremy Drake wrote:
>> I for one am greatly looking forward to tsearch2 being in core. I
>> was very fond of the plugin mechanism, until I signed up with a
>> hosting provider.
>
> Yes, you have told us about your hosting provider before. Just make
> sure your next hos
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> Another question that would be easier to resolve before the patch is
>> committed is naming: the patch currently uses a mix of "full text" and
>> "tsearch[2]" as the name of the full-text search feature. If we're going
>> to b
Peter Eisentraut wrote:
Andrew Dunstan wrote:
contrib is a horrible misnomer. Can we maybe bite the bullet and call
it something else?
plugins?
standard-plugins might be more informative. I think of them as being
like perl's standard modules, things that are part of the standard
Neil Conway wrote:
> On Wed, 2007-01-24 at 13:49 -0500, Tom Lane wrote:
>> 2) once we put this in core we are going to be stuck with supporting its
>> SQL API forever. Are we convinced that this API is the one we want?
>> I don't recall even having seen any proposal or discussion.
>
> There has b
Neil Conway wrote:
> But I agree that we need considerably more discussion before
> committing the patch. I'm personally not sold on the need for
> modifications to the SQL grammar, for example, as opposed to just
> using a set of SQL-callable functions and some new system catalogs.
In particular,
Peter Eisentraut wrote:
> Jeremy Drake wrote:
>> I for one am greatly looking forward to tsearch2 being in core. I
>> was very fond of the plugin mechanism, until I signed up with a
>> hosting provider.
>
> Yes, you have told us about your hosting provider before. Just make
> sure your next hos
Jeremy Drake wrote:
> I for one am greatly looking forward to tsearch2 being in core. I
> was very fond of the plugin mechanism, until I signed up with a
> hosting provider.
Yes, you have told us about your hosting provider before. Just make
sure your next hosting provider does not refuse to in
Jeff Davis wrote:
> On that point, why do we have /contrib? It's for "plugins" that are
> so version-dependent that they can't exist as a separate project, as
> I understand it.
No. (I don't know a better and succinct answer, but that is not it.)
--
Peter Eisentraut
http://developer.postgresql.
Andrew Dunstan wrote:
> contrib is a horrible misnomer. Can we maybe bite the bullet and call
> it something else?
plugins?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 6: explain analyze is your friend
Jeremy Drake wrote:
On Wed, 24 Jan 2007, Peter Eisentraut wrote:
I still haven't heard any argument for why this would be necessary or
desirable at all, other than that it looks better for marketing
reasons, which I will counter by saying that it looks worse for
marketing reasons because our
On Wed, 2007-01-24 at 13:49 -0500, Tom Lane wrote:
> 2) once we put this in core we are going to be stuck with supporting its
> SQL API forever. Are we convinced that this API is the one we want?
> I don't recall even having seen any proposal or discussion.
There has been some prior discussion:
Jeremy Drake wrote:
> On Wed, 24 Jan 2007, Peter Eisentraut wrote:
>
>> Teodor Sigaev wrote:
>>> If there aren't objections then we plan commit patch tomorrow or
>>> after tomorrow.
>> I still haven't heard any argument for why this would be necessary or
>> desirable at all, other than that it loo
On Wed, 24 Jan 2007, Peter Eisentraut wrote:
> Teodor Sigaev wrote:
> > If there aren't objections then we plan commit patch tomorrow or
> > after tomorrow.
>
> I still haven't heard any argument for why this would be necessary or
> desirable at all, other than that it looks better for marketing
>
On Wed, Jan 24, 2007 at 01:53:54PM -0500, Andrew Dunstan wrote:
> Joshua D. Drake wrote:
> >Peter Eisentraut wrote:
> >
> >>Teodor Sigaev wrote:
> >>
> >>>If there aren't objections then we plan commit patch tomorrow or
> >>>after tomorrow.
> >>>
> >>I still haven't heard any argument f
On Wed, 2007-01-24 at 19:15 +0100, Peter Eisentraut wrote:
> Teodor Sigaev wrote:
> > If there aren't objections then we plan commit patch tomorrow or
> > after tomorrow.
>
> I still haven't heard any argument for why this would be necessary or
> desirable at all, other than that it looks better
Joshua D. Drake wrote:
Peter Eisentraut wrote:
Teodor Sigaev wrote:
If there aren't objections then we plan commit patch tomorrow or
after tomorrow.
I still haven't heard any argument for why this would be necessary or
desirable at all, other than that it looks better for market
> Teodor Sigaev wrote:
>> If there aren't objections then we plan commit patch tomorrow or
>> after tomorrow.
This is a fairly large patch and I would like the chance to review it
before it goes in --- "we'll commit tomorrow" is not exactly a decent
review window.
Peter Eisentraut <[EMAIL PROTECT
Peter Eisentraut wrote:
> Teodor Sigaev wrote:
>> If there aren't objections then we plan commit patch tomorrow or
>> after tomorrow.
>
> I still haven't heard any argument for why this would be necessary or
> desirable at all, other than that it looks better for marketing
> reasons, which I wil
Teodor Sigaev wrote:
> If there aren't objections then we plan commit patch tomorrow or
> after tomorrow.
I still haven't heard any argument for why this would be necessary or
desirable at all, other than that it looks better for marketing
reasons, which I will counter by saying that it looks wo
78 matches
Mail list logo
