On Wed, May 01, 2002 at 12:56:00AM -0400, Tom Lane wrote:
> "Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> >>> GNUe will break, as well.
> > I'm willing to implement whatever clever solution we all come up with.
>
> If you need help in inventing a solution, it'd be a good idea to explain
> the
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
>>> GNUe will break, as well.
> I'm willing to implement whatever clever solution we all come up with.
If you need help in inventing a solution, it'd be a good idea to explain
the problem. Personally I'm not familiar with GNUe ...
On Wed, May 01, 2002 at 12:03:00AM -0400, Tom Lane wrote:
> "Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> > GNUe will break, as well.
>
> Do I hear a volunteer to fix it?
I'm willing to implement whatever clever solution we all come up with.
I'll have to coordinate w/ the GNUe IRC folks to g
Ian Barwick <[EMAIL PROTECTED]> writes:
> How can I restrict the query to the schemas in the
> current search path, i.e. the schema names returned
> by SELECT current_schemas() ?
Well, this is the issue open for public discussion.
We could define some function along the lines of
"is_visible_tab
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> I think it would be much faster simply to list of the programs that
> use Postgresql internals that won't break.
Approximately none, I'm sure :-(. This thread isn't about that, it's
about stirring up the troops to fix everything that must be fixed.
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> GNUe will break, as well.
Do I hear a volunteer to fix it?
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
I think it would be much faster simply to list of the programs that
use Postgresql internals that won't break.
--
Rod
- Original Message -
From: "Ross J. Reedstrom" <[EMAIL PROTECTED]>
To: "Christopher Kings-Lynne" <[EMAIL PROTECTED]>
Cc: "Dave Page" <[EMAIL PROTECTED]>; "Tom Lane"
<[EMAIL
On Wed, May 01, 2002 at 10:05:23AM +0800, Christopher Kings-Lynne wrote:
>
> phpPgAdmin (WebDB) will be broken as well. I think myself and at least a
> few other committers lurk here tho.
>
> Other things that will break:
>
> TOra
> Various KDE interfaces
GNUe will break, as well.
Ross
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> What about "CREATE USER tgl WITH SCHEMA;" ?
Uh, what about it? It's not a standard syntax AFAIK.
If I were running an installation where I wanted "one schema per user"
as default, I'd rather have an "auto_create_schema" SET parameter that
> produces a result like this:
>
> schema | object
> +
> public | abc
> foo| abc
> foo| xyz
> bar| xyz
> (4 rows)
>
> How can I restrict the query to the schemas in the
> current search path, i.e. the schema names returned
> by SELECT current_schemas() ?
Now, if w
> test=# CREATE USER tgl;
> CREATE USER
> test=# CREATE SCHEMA tgl AUTHORIZATION tgl;
> CREATE
What about "CREATE USER tgl WITH SCHEMA;" ?
Which will implicitly do a "CREATE SCHEMA tgl AUTHORIZATION tgl;"
Chris
---(end of broadcast)---
TIP 1: s
Hi,
PureFTPd has got really good Postgres support:
Authenticates off postgres, with definable queries to return stuff like
homedirs, quotas, password hashes, etc.
Cool.
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go
> > JDBC and ODBC metadata code is certainly broken; so are the
> > catalog lookups in pgaccess, pgadmin, and so on. psql and
> > pg_dump are broken as well (though I will take responsibility
> > for fixing pg_dump, and will then look at psql if no one else
> > has done it by then). I'm not even
> For commands
> that accept wildcard patterns, what should happen --- should "\z my*"
> find these tables, if they're not in my search path? Is "\z f*.my*"
> sensible to support? I dunno yet.
Technical question - this query:
SELECT nspname AS schema,
relname AS object
FRO
I'm working on a revised patch for PREPARE/EXECUTE. The basic code
has been written (although I've been delayed due to the workload at
school). I'm now trying to add support for preparing queries with
parameters, but it is failing at an early stage of the game:
nconway=> prepare q1 as select 1;
P
Bill Cunningham <[EMAIL PROTECTED]> writes:
> So we now have a default schema name of the current user?
> ... This is exactly how DB2 operates, implict schemas for each user.
You can operate that way. It's not the default though; the DBA will
have to explicitly do a CREATE SCHEMA for each user.
Tom Lane wrote:
>Bill Cunningham <[EMAIL PROTECTED]> writes:
>
>>I would think this should produce the following:
>>
>
>>test=# \d mytab
>>Table "bar.mytab"
>> Column | Type | Modifiers
>>+-+---
>> f1 | text|
>> f1 | integer |
>>
>
>>Table "f
On Tue, Apr 30, 2002 at 03:28:13PM -0400, Tom Lane wrote:
> Andrew Sullivan <[EMAIL PROTECTED]> writes:
> > ... In any case, I can't offer a definite
> > answer about the 64-bit qsort for now.
>
> Do you need to profile it? It seemed that the 32-bit behavior for
> many-equal-keys was so bad that
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: 30 April 2002 18:32
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [INTERFACES] Schemas: status report, call for developers
>
>
> Current CVS tip has most of the needed infrastructure for
> SQL-spec schem
I think DBD::Pg driver very much depends on system tables.
Hope, Jeffrey (current maintainer) is online.
regards,
Oleg
On Tue, 30 Apr 2002, Tom Lane wrote:
> Current CVS tip has most of the needed infrastructure for SQL-spec
> schema support: you can create schemas, and
Sorry to reply to myself, but this might be useful for the archive.
On Tue, Apr 30, 2002 at 11:55:53AM -0400, Andrew Sullivan wrote:
> But now I'm wondering, is there anyone who knows of troubles with the
> profiling of programs compiled with -pg under gcc 3.0.3 64 bit on
> Solaris 7? Here's my
Bill Cunningham <[EMAIL PROTECTED]> writes:
> I would think this should produce the following:
> test=# \d mytab
> Table "bar.mytab"
> Column | Type | Modifiers
> +-+---
> f1 | text|
> f1 | integer |
> Table "foo.mytab"
> Column | Type
>
>Here's an example of what's broken:
>
>test=# create schema foo;
>CREATE
>test=# create table foo.mytab (f1 int, f2 text);
>CREATE
>test=# create schema bar;
>CREATE
>test=# create table bar.mytab (f1 text, f3 int);
>CREATE
>test=# \d mytab
>Table "mytab"
> Column | Type | Modifier
Current CVS tip has most of the needed infrastructure for SQL-spec
schema support: you can create schemas, and you can create objects
within schemas, and search-path-based lookup for named objects works.
There's still a number of things to be done in the backend, but it's
time to start working on
On Wed, Apr 03, 2002 at 11:35:30AM -0500, Tom Lane wrote:
> Andrew Sullivan <[EMAIL PROTECTED]> writes:
>
> > ... so we can be fairly certain the problem is in the
> > 32 bit library. Maybe the 64 bit one is better?
>
> Good point. Please check it out and let us know.
Sorry this has taken me
On Tue, Apr 30, 2002 at 10:39:38AM -0400, Tom Lane wrote:
> Karel Zak <[EMAIL PROTECTED]> writes:
> > There must be possible define some callback specific data too, the
> > callback maybe will search query in some own specific cache and it
> > require some key.
>
> Yeah, I have it set up simil
Karel Zak <[EMAIL PROTECTED]> writes:
> There must be possible define some callback specific data too, the
> callback maybe will search query in some own specific cache and it
> require some key.
Yeah, I have it set up similarly to on_proc_exit callbacks: when you
register the callback functio
On Tue, Apr 30, 2002 at 09:43:29AM -0400, Tom Lane wrote:
> Karel Zak <[EMAIL PROTECTED]> writes:
> > I have a question, how I will know how changes are relevant for my
> > query plan? IMHO is needful some hight-level API, like
>
> > list = ExtractQueryPlanOids( plan );
> > reg = Regis
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> 5. Ignore the current code which allows functions to return multiple
>> results as expressions; we can leave it there, but deprecate it with the
>> intention of eventual removal.
> What does the current 'setof' pl/pgsql business actually _d
Karel Zak <[EMAIL PROTECTED]> writes:
> I have a question, how I will know how changes are relevant for my
> query plan? IMHO is needful some hight-level API, like
> list = ExtractQueryPlanOids( plan );
> reg = RegisterOidsCallback( list, mycallback, mycallbackdata );
Yes, some kind o
BDY.RTF
Description: RTF file
BDY.RTF
Description: RTF file
> Is anyoune working on information schema (or pg_xxx views) for use
in
> psql and other development frontends?
I had started to try an information schema. Didn't make it very far.
Way too much information missing to come anywhere near spec -- so I've
started trying to fill in those holes.
Give
On Tue, 2002-04-30 at 03:35, Bruce Momjian wrote:
>
> I think you have to use the backend pid to find your own. I think
> there is a libpq function that returns the backend pis so psql can
> frame the proper query.
Is anyoune working on information schema (or pg_xxx views) for use in
psql and o
On Tue, 2002-04-30 at 03:35, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Appears psql needs to know how to differentiate between it's own temp
> > tables and those of another connection.
>
> More generally, psql is as yet clueless about schemas.
>
> regression=# create schema fo
On Mon, Apr 29, 2002 at 03:43:30PM -0400, Tom Lane wrote:
> I'm planning to add a mechanism to backend/utils/cache/inval.c that will
> allow additional modules to register to get notification of syscache and
> relcache invalidation events. Right now, only the syscache and relcache
> get told abou
36 matches
Mail list logo
