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 r
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 i
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 th
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 ha
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 specifi
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 sea
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 tsearch
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
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
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,
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
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
contrib.v
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 t
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:
>
>
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 'contrib'
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
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 itsel
18 matches
Mail list logo
