[HACKERS] [ppa][PATCHES] Argument handling improvements
Below are links for the patch and binary (image) files for argument handling improvements in ppa. You can view the original concept @ http://jawed.name/pgsql_soc. It provides support for both JS and JS deficient users. I tried to keep it within the coding guidelines set forth. I appreciate and look forward to any sort of feedback, as this is a SoC project, suggestions are welcome. http://jawed.name/pgsql_soc/jsargs.patch http://jawed.name/pgsql_soc/jsargs.tar.gz Regards, John ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Snowball and ispell in tsearch2
OpenFTS ebuild: http://bugs.gentoo.org/show_bug.cgi?id=135859 It has a USE flag for the snowball stemmer. I can take care of packaging for Gentoo if it will free up time for you to work on other distros. John PS, upstream package size isn't, and shouldn't be an issue, it should be left to the packaging systems to discretely fetch what is needed. On 6/7/06, Markus Schiltknecht [EMAIL PROTECTED] wrote: That said, I don't necessarily mean that all stemmers must be included in CVS or such. It should just be simpler for the database administrator to install ispell or stemmer 'modules'. A non-plus-ultra solution would be to provide packages for each language (in debian or fedora, etc..). I'd be willing to help with such a project. I have experience with tsearch2 as well as with gentoo and debian packaging. I can't help with rpm, though. Regards Markus Teodor Sigaev wrote: We got a lot requests about including stemmers and ispell dictionaries for all accessible languages into tsearch2. I understand that tsearch2 will be closer to end user. But sources of snowball stemmers is about 800kb, each ispell dictionaries will takes about 0.5-2M. All sizes are sized with compression. I am afraid that is too big size... What are opinions? ---(end of broadcast)--- TIP 6: explain analyze is your friend ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Connection Broken with Custom Dicts for TSearch2
Since we are on the topic, is there a timeline/plans for openfts being brought into core? If not, I'll continue my work on bringing it into Gentoo Portage. John On 6/5/06, Oleg Bartunov oleg@sai.msu.su wrote: On Mon, 5 Jun 2006, Teodor Sigaev wrote: Teodor Sigaev wrote: Sorry, it isn't mentioned on page, but this example of code working only with before 8.1 versions. In 8.1 interface to dictionary was changed. Try attached dict_tmpl.c 2Oleg: place file on site, pls done Regards, Oleg _ Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru), Sternberg Astronomical Institute, Moscow University, Russia Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(495)939-16-83, +007(495)939-23-83 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Improving ALTER TYPE support
I guess I don't understand what one has to do with the other (SRF's returning records and OUT parameters). I always thought they were exclusive, could you elaborate?On 5/24/06, Tom Lane [EMAIL PROTECTED] wrote: Josh Berkus josh@agliodbs.com writes: I've been working on a function which returns a setof a composite type. Everytime I've changed the structure of the returning setof, I've had to change the type accordingly, which current means doing a drop type ... cascade down to the function. We should allow one of the following: Why not go all the way and work out a way to define an SRF return type as a part of the function?e.g.Um, isn't that exactly what the OUT parameter support already gives you,ie, an anonymous record type?regards, tom lane
Re: [HACKERS] Improving ALTER TYPE support
Ok, this way works and the proposed way isn't necessary. On 5/24/06, Tom Lane [EMAIL PROTECTED] wrote: John Jawed [EMAIL PROTECTED] writes: I guess I don't understand what one has to do with the other (SRF's returning records and OUT parameters). I always thought they were exclusive, could you elaborate? (BTW, please don't post uselessly HTML-ified mail.) If you write something like create function foo (in p1 int, out r1 int, out r2 text) returns setof record then you've effectively got a function returning an anonymous composite type (here, with one int and one text column). I don't see a case for inventing a separate facility that will pretty much just duplicate this functionality. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Improving ALTER TYPE support
I've been working on a function which returns a setof a composite type. Everytime I've changed the structure of the returning setof, I've had to change the type accordingly, which current means doing a drop type ... cascade down to the function. We should allow one of the following: 1) Add a REPLACE on CREATE TYPE (create or replace type)2) Allow ALTER TYPE to alter the definition of the type (currently it only allows changes to schema and ownership)It may get tricky with the first option because there'd be orphaned dependencies on objects which reference that particular type while it's being re-created. I'll work on a patch according to feedback.
Re: [HACKERS] Improving ALTER TYPE support
Makes more sense to do that, and I think it'll be cleaner to implement as well.On 5/23/06, Josh Berkus josh@agliodbs.com wrote:John, I've been working on a function which returns a setof a composite type. Everytime I've changed the structure of the returning setof, I've had to change the type accordingly, which current means doing a drop type ... cascade down to the function. We should allow one of the following: Why not go all the way and work out a way to define an SRF return type as apart of the function?e.g.CREATE OR REPLACE FUNCTION some_srf ( param1 int, param2 text )RETURNS some_srf ( col1 int, col2 numeric ) AS Then the replace function would automatically rebuild the type.--Josh BerkusPostgreSQL @ SunSan Francisco---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
