That would be great if a C function could find out what schema it had
been declared in, but I don't think it can readily do so.
TODO candidate ?
Seems like it would be a good thing.
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
That would be great if a C function could find out what schema it had
been declared in, but I don't think it can readily do so.
TODO candidate ?
Seems like it would be a good thing.
I take that back: you can find it out if you really want
On Wed, 12 May 2004, Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
2. When an object foo is called and needs to refer to another object
bar, it should assume that bar exists in the same schema as foo, and NOT
in the current search_path.
That would be great if a C
Did you guys find any solution to this in the end?
Chris
Oleg Bartunov wrote:
Thanks Christopher,
we'll look into the issue.
Oleg
On Fri, 7 May 2004, Christopher Kings-Lynne wrote:
I have a table with a tsearch2 index on it. Now, I have all the
tsearch2 stuff installed into a
On Wed, 12 May 2004, Christopher Kings-Lynne wrote:
Did you guys find any solution to this in the end?
Not yet. Could you send me a simple test suite ? I'm not
experienced with schema and don't know how to load tsearch2 into
specific schema.
Oleg
Chris
Oleg Bartunov wrote:
Christopher, I don't quite understand the problem
Did you move pg_ts_* table to schema 'contrib' ?
What functions you schema-qualified and how ?
It's always required to set search_path properly.
Oleg
On Wed, 12 May 2004, Christopher Kings-Lynne wrote:
Did you guys find any solution to this in
OK, I'll try to explain it better.
1. Tsearch2 requires access to several tables.
2. You can edit the tsearch2.sql script and change the set schema =
... to contrib.
3. You load all the tsearch2 objects into contrib.
4. You create a table in the public schema with a column of type
Christopher,
On Wed, 12 May 2004, Christopher Kings-Lynne wrote:
OK, I'll try to explain it better.
1. Tsearch2 requires access to several tables.
2. You can edit the tsearch2.sql script and change the set schema =
... to contrib.
Aha, this is what I thought about.
3. You load all the
6. However, it is now not possible to restore the sql script as it was
dumped, as you get this error:
ERROR: relation pg_ts_cfg does not exist
No problem,
[EMAIL PROTECTED]:~/app/pgsql/tsearch2/test_scheme$ createdb qq
CREATE DATABASE
[EMAIL PROTECTED]:~/app/pgsql/tsearch2/test_scheme$ psql
Christopher,
here is a cut'n paste from test script (patch applied):
dropdb qq
createdb qq
psql qq -c create schema contrib;
psql qq tsearch2_contrib-2.sql
psql qq -c create table test ( a text, fts contrib.tsvector);
psql qq -c insert into test(a) values ('I hit a dog');
psql qq -c set
No problem,
Actually, I did some more testing and I properly understand the problem
now - and it won't happen in the general restoring case.
What fails is if you pg_dump -a to just dump the DATA from a table
containing a tsearch2 trigger that is in a different schema.
Then you delete all the
On Wed, 12 May 2004, Christopher Kings-Lynne wrote:
No problem,
Actually, I did some more testing and I properly understand the problem
now - and it won't happen in the general restoring case.
What fails is if you pg_dump -a to just dump the DATA from a table
containing a tsearch2 trigger
Oleg Bartunov [EMAIL PROTECTED] writes:
Hmm, what other hackers thinks ? This is not just a tsearch2 problem,
it could happens with any such kind of things, like defining user defined
type in one scheme, using it in another, dumping separate data.
Could pg_dump be enough smart to set
It could not. I think the fundamental point here is that it is a real
bad idea for the tsearch routines to make any assumptions about the
current search path. What I would suggest is that the internal objects
used by the tsearch routines (such as pg_ts_cfg) should be required to
live in a
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
2. When an object foo is called and needs to refer to another object
bar, it should assume that bar exists in the same schema as foo, and NOT
in the current search_path.
That would be great if a C function could find out what schema it had
That would be great if a C function could find out what schema it had
been declared in, but I don't think it can readily do so.
There's no context information available to it at all? Even if you go
contrib.tsearch2 qualfication?
How about making it so that the default context for functions is
I have a table with a tsearch2 index on it. Now, I have all the
tsearch2 stuff installed into a 'contrib' schema. I have had to change
the default database schema to include the contrib schema as
behind-the-scenes, tsearch2 looks for its tables, and cannot find them
even if the function
Thanks Christopher,
we'll look into the issue.
Oleg
On Fri, 7 May 2004, Christopher Kings-Lynne wrote:
I have a table with a tsearch2 index on it. Now, I have all the
tsearch2 stuff installed into a 'contrib' schema. I have had to change
the default database schema to include the
18 matches
Mail list logo
