On Tue, 2002-07-23 at 11:34, Tom Lane wrote:
> [EMAIL PROTECTED] (Neil Conway) writes:
> > Regarding the syntax for EXECUTE, it occurs to me that it could be made
> > to be more similar to the PREPARE syntax -- i.e.
>
> > PREPARE foo(text, int) AS ...;
>
> > EXECUTE foo('a', 1);
>
> > (rather t
On Sun, 2002-07-21 at 21:20, Christopher Kings-Lynne wrote:
> > Now that we have dependencies implemented, it would be a real good idea
> > if operator classes could be included in the web of dependencies.
> > However, the pg_depends code implicitly assumes that it can do a DROP,
> > if demanded,
> server powered by PostgreSQL, the third most popular database, and a
>
>^
> Wonder why we are "the third most popular database". I think that's
> good?
You'll notice they didn't qualify where. On this list, it's probably
#1. Within Progress software perhaps we'
On Wed, 2002-07-17 at 04:36, Christopher Kings-Lynne wrote:
> Hi All,
>
> Has anyone committed something that would cause me to be getting doubles of
> all my ELOG messages? Or is it something I've changed in my local CVS?
You probably started the daemon without redirecting the server logs to a
For all intent and purpose, pg_index.indisprimary can be added to that
list. Can't make a primary key without a pg_constraint entry.
The below are also reported unused by the documentation:
pg_class.relukeys
pg_class.relfkeys
pg_class.relrefs
pg_index.indisclustered
pg_index.indreference
On
On Mon, 2002-07-15 at 11:30, Christopher Kings-Lynne wrote:
> OK, more DROP COLUMN funny business:
>
> Assuming that selects, updates and deletes all ignore the dropped column,
> what happens with things like alter table statements?
>
> You can still quite happily set the default for a dropped c
On Sun, 2002-07-14 at 21:19, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I've been running a few functions within schema's. It's annoying that
> > everything needs to be qualified as it doesn't allow the functions to be
> > moved v
On Sun, 2002-07-14 at 20:36, Rod Taylor wrote:
> I've been running a few functions within schema's. It's annoying that
> everything needs to be qualified as it doesn't allow the functions to be
> moved very easily.
>
>
> Would it be appropriate for the fun
RAISE seems to be quite wonky.
The below function fails to compile due to the function call in the
arguement.
create function test(text)
returns bool
as '
begin
raise exception ''test %'', quote_literal($1);
return false;
end;
' language plpgsql;
Likewise, the below fails to compil
I've been running a few functions within schema's. It's annoying that
everything needs to be qualified as it doesn't allow the functions to be
moved very easily.
Would it be appropriate for the function to have it's own schema as
pre-pended onto the user path while in the users function?
--
On Sat, 2002-07-13 at 10:29, Bruce Momjian wrote:
> Rod Taylor wrote:
> > > > I prefer ...add constraint. After a while (release or 2) removal of
> > > > create unique index all together.
> > >
> > > Remove CREATE UNIQUE INDEX entirely? Why?
>
On Sat, 2002-07-13 at 10:27, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I noticed that SERIAL sequences aren't dropping with the application of
> > the patch.
>
> > Was this intentional?
>
> Yeah, the dependency isn't stored yet.
> > I prefer ...add constraint. After a while (release or 2) removal of
> > create unique index all together.
>
> Remove CREATE UNIQUE INDEX entirely? Why?
I was looking to encourage users to use core SQL as I spend more time
than I want converting between systems -- thanks in part to users wh
I'm going to change the pg_dump command to pull these constraints out of
pg_constaint where possible, creating the appropriate alter table add
constraint command (see primary key).
Should unique constraints created with 'create index' (no entry in
pg_constraint) be re-created via alter table add
On Fri, 2002-07-12 at 15:17, Tom Lane wrote:
> Now that the pg_depend mechanism is mostly in there, it is no longer
> a good idea to delete things directly (for example, by calling
> heap_drop_with_catalog or even just heap_delete'ing a catalog tuple).
I noticed that SERIAL sequences aren't dropp
> * Add pg_depend table for dependency recording; use sysrelid, oid,
> depend_sysrelid, depend_oid, name
> * Auto-destroy sequence on DROP of table with SERIAL; perhaps a separate
> SERIAL type
> * Have SERIAL generate non-colliding sequence names when we have
>
I see this on the TODO list:
# Fix PL/PgSQL to handle quoted mixed-case identifiers
Perhaps you could make a view (alias the names with spaces) to work on?
On Fri, 2002-07-12 at 06:31, eutm wrote:
>
> Dear Sirs!:)I encounted one small problem,working with
> PostgreSQL 7.3devel.It can
> > Changing data types probably won't appear. I don't know of anyone
> > working on it -- and it can be quite a complex issue to get a good
> > (resource friendly and transaction safe) version.
>
> I'd be happy with a non-resource friendly and non-transaction-safe version
> over not having the
> However, is there an easy way of obtaining the list of columns (and their
> types/indexes/etc) in a table, so that we can recreate table a with just
> that column missing? One which won't break when the underlying pg_* schema
> changes?
I see. No, not that I know of. You could take an SQL du
On Wed, 2002-07-10 at 19:44, Bradley Baetz wrote:
>
>
> Note that before bugzilla really supports postgresql, we (ie the bugzilla
> team) are going to need DROP COLUMN support, as well as support for
> changing a field's type. This is because thats how upgrades are done, when
> new features chan
On Wed, 2002-07-10 at 18:33, Tom Lane wrote:
> Consider
>
> CREATE TABLE foo (f1 int primary key);
>
> CREATE TABLE bar (f1 int references foo);
>
> DROP TABLE foo RESTRICT;
> Our historical behavior is to allow the drop, while issuing a notice
> about implicit deletion of tr
> Can the ports system take into account the space required for a dumpfile?? :-)
It cheats by keeping a backup of the old version -- makes an installable
package out of the currently installed version. This is removed once
the package has been successfully upgraded (including dependencies).
On
On Tue, 2002-07-09 at 19:09, Lamar Owen wrote:
> On Tuesday 09 July 2002 04:17 pm, Hannu Krosing wrote:
> > On Tue, 2002-07-09 at 22:10, Lamar Owen wrote:
> > > The pre-upgrade script is run in an environment that isn't robust enough
> > > to handle that. What if you run out of disk space during
> Seems I have a funny case left (Note the last comparison should be
> false):
Ugh... I forgot to initialize the result -- so it picked up the previous
calls value.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archi
I've nearly finished off the patch Christopher distributed. Creates the
between node, and passes all regression tests except horology. I need
to update outfuncs and readfuncs -- but hope to fix the below first.
Seems I have a funny case left (Note the last comparison should be
false):
regress
> > and not simply a lock on the pg_constraint table
>
> In this context, a lock on pg_constraint *is* global, because it will
> mean that no one else can be creating an index on some other table.
> They'd need to hold that same lock to ensure that *their* chosen
> constraint name is unique.
So
> I don't buy that argument even for foreign keys --- and remember that
> pg_constraint will also hold entries for CHECK, UNIQUE, and PRIMARY KEY
> constraints. I don't want to have to take a global lock whenever we
> create an index.
I don't understand why a global lock is necessary -- and not
> > It should also be noted that an ALTER TABLE / SET TYPE implemented with
> > the above idea with run into the 2x diskspace issue as well as take
> > quite a while to process.
>
> I think that if the 'SET TYPE' operation is ever to be rollback-able, it
> will need to use 2x diskspace. If it's
> all values, drop the old col). So, there is no reason why this new
> attisdropped field shouldn't allow us to implement a full ALTER TABLE/SET
> TYPE sort of feature - cool huh?
I've not looked in a while, but the column rename code did not account
for issues in foreign keys, etc. Those shou
On Tue, 2002-07-02 at 17:12, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Of course, a shared memory system probably is going to either do it
> > > sequentailly or have its own index issues, so I don't see a huge
> > > advantage to going to shared memo
> One problem I see is that pg_constraint entries can *only* be associated
> with relations; so the table has no way to represent constraints
> associated with domains --- not to mention assertions, which aren't
It's ugly, but one could make the relid 0, and add a typeid which is
non-zero to repr
On Thu, 2002-06-27 at 02:52, Tim Hart wrote:
>
>
> Begin forwarded message:
>
> I said:
> > BTW - Oracle & other commercial vendors handle these contingencies by
> > buying insurance policies.
>
> I think I should probably correct the above statement. I think Oracle
> specifically has a larg
> > Also, someone suggested listing the by-month indexes back-to-front
> > (most recent month first), which seems like a great idea if not
> > difficult.
>
> Better?
>
> http://archives.postgresql.org/pgsql-jdbc
>
> The rest will 'fall in line' once there is something for mhonarc to work
> on a
Kinda like the blind leading the blind, but:
I'm assuming you will need to do something similar to what you did in
the previous version in gram.y. That is, create an expression node with
the appropriate equations and pass that through ExecEvalExpr().
You can probably return the true or false fr
> > Vince, we can get -advocacy listed on the web site? There has been no
> > traffic over there until now, but there are ppl subscribed to it ...
>
> all done.
Any chance of getting a pgsql-patches link on archives.postgresql.org?
I know the archives are created (I use them) but there is no o
On Wed, 2002-06-26 at 22:30, Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > It would be nice if the recursive dependency checking function was
> > available as an end user function too, so you could analyze dependencies
> > before even trying to drop something, or even just to unde
> * Give an error, same as if "ONLY foo" had been written.
>
> * Assume the user really wants recursion, and do it anyway.
>
> The second seems more user-friendly but also seems to violate the
> principle of least surprise. Anyone have an opinion about what to do?
I really prefer t
On 2002.06.23 01:23 Christopher Kings-Lynne wrote:
> > Some have expressed that this could be quite slow for large
> databases,
> > and want a type of:
> >
> > SET CONSTRAINTS UNCHECKED;
> >
> > However, others don't believe constraints other than foreign keys
> > should go unchecked.
>
> Well, a
With the pg_depend / pg_constraint implementation foreign keys are
applied to dumps via alter table / add foreign key (retains inter
table dependencies).
Some have expressed that this could be quite slow for large databases,
and want a type of:
SET CONSTRAINTS UNCHECKED;
However, others don't b
bash-2.05a$ make install > /dev/null
In file included from tupdesc.c:22:
../../../../src/include/funcapi.h:69: syntax error before `uint'
Dropping the u works fine.
FreeBSD fury.inquent.com 4.5-RELEASE FreeBSD 4.5-RELEASE #1: Mon Feb 4
13:30:57 EST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/
For some reason a view with a select distinct, an order and an exception
by will cause pg_dump to output a double order by -- one for each select
which of course is bad SQL.
PSQL
rbt_t=# create view test as select distinct relname, reltuples, relnatts
from pg_class where relkind = 't' excep
I have a few questions about what would be expected from coercing to a
type with constraints (Domains mostly -- but complex object types may
run into similar issues if implemented).
What I intend to do:
In gram.y, remove the application of typename directly to the A_Const
in makeTypeCast. Use Ty
> I'm also looking at the SQL99 INFORMATION_SCHEMA views. Is anyone
> already defining these? Is someone interested in picking this up?
I've
> got some definitions in a contrib-style directory but have not yet
> mapped them to PostgreSQL.
I have a few of the basics done, but nothing really signif
mp;&
! // ((A_Const *) arg)->typename == NULL)
! // {
! // ((A_Const *) arg)->typename = typename;
! // return arg;
! // }
! // else
! // {
TypeCast *n = makeNode(TypeCast);
n->arg = arg;
n->typename = typename;
return (Node *) n;
! // }
}
static Node *
--
Rod
> > I think that when SERIAL is used, the sequence should be tied
> > inextricably to the table which created it, and it should be
hidden from
> > use for other purposes (perhaps similar to the way a toast table
is). If
> > you *want* to use a sequence across several tables, then you don't
use
> >
> What happens is the sequence is shared between several tables (eg.
invoice
> numbers or something)
You cannot accomplish this situation by strictly using the SERIAL
type.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http:
Thats fair, and makes the job a heck of a lot simpler.
We do need to change the sequence naming once. They have a tendency
to conflict at the moment.
--
Rod
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Rod Taylor" <[EMAIL PROTECTED
e" <[EMAIL PROTECTED]>
To: "Rod Taylor" <[EMAIL PROTECTED]>
Cc: "Hackers List" <[EMAIL PROTECTED]>
Sent: Thursday, June 13, 2002 5:52 PM
Subject: Re: [HACKERS] Making serial survive pg_dump
> "Rod Taylor" <[EMAIL PROTECTED]> writes:
> &g
--
Rod
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Rod Taylor" <[EMAIL PROTECTED]>
Cc: "Hackers List" <[EMAIL PROTECTED]>
Sent: Thursday, June 13, 2002 9:46 AM
Subject: Re: [HACKERS] Making serial survive pg_dump
>
sage -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Rod Taylor" <[EMAIL PROTECTED]>
Cc: "Hackers List" <[EMAIL PROTECTED]>
Sent: Thursday, June 13, 2002 5:41 PM
Subject: Re: [HACKERS] Making serial survive pg_dump
> "Rod Taylor" <[
Currently serial is dumped as a sequence and appropriate default
statement.
With my upcoming dependency patch serials depend on the appropriate
column. Drop the column (or table) and the sequence goes with it.
The depencency information does not survive the pg_dump / restore
process however as i
After uncommenting this I receive errors about it not being a valid
option. I assume this has been replaced by
(server|client)_min_messages?
In which case it should be removed from what initdb installs.
--
Rod
---(end of broadcast)---
TIP 2: you
Sounds great to me. Mostly why I made the remark that I wasn't happy
with the solution due to using type unknown.
any and _any it is.
--
Rod
- Original Message -
From: "Nicolas Bazin" <[EMAIL PROTECTED]>
To: "Rod Taylor" <[EMAIL PROTECTED]>; "
I really like array iterators, and am interested in simplifying them
somewhat. Currently they required too many operator entries and
functions to be truely useful in the base.
Please fill in holes ;)
Ok, first step. The ability to create an operator that will work on a
vast number of data type
> Doesn't seem very workable for the public schema. I suspect pg_dump
> has to special-case public anyway, to some extent, but this doesn't
> really get us around the DROP problem for individual objects AFAICS.
Most people in the know will probably never use public due to
portability issues betw
> No, it's a necessary thing to comply with the SQL standard.
> The standard thinks all the predefined names are keywords and
> should override user names. Therefore there *must* be a mode
Hmm.. I'm not fond of this part of the standard in this case -- though
it's got to be there for good reaso
> A limited-to-that-table dump/fix/restore can be a problem because of
the
> interrelationships of RI among tables. If there were any easier way
to dump
> information about a table so that I could restore the RI that other
tables
> have on it, that might be a solution.
Agreed about making that ea
> set search_path = my_schema;
> This works fine unless the object name duplicates a system object;
> in that case, since the effective search path is really "pg_catalog,
> my_schema", the DROP will find and try to drop the system object.
I must have missed that day. Why is that exactly? Clien
It appears it scanes the type_idx once per opereator. IN gets broken
down into ORs
Is this what the TODO entry 'Make IN / NOT IN have similar performance
as EXISTS' means?
--
Rod
- Original Message -
From: "Oleg Bartunov" <[EMAIL PROTECTED]>
To: "Pgsql Hackers" <[EMAIL PROTECTED]>; "Tom
Of course, something else you may want to do is is allow postgresql to
use a whack load more sort space in ram -- assumming you have ram
free.
Its probably hitting the disk alot for temporary storage space.
http://www.ca.postgresql.org/docs/momjian/hw_performance/
http://www.argudo.org/postgresq
The big problem with the query probably isn't the scans due to your
dataset and the way indexes work.
I'm actually rather surprised it chose an index in the smaller table.
It's the agregate thats taking the time. Which means, faster CPU or
simpler aggregate will do the trick. Ie. Do you really
m: "Joel Burton" <[EMAIL PROTECTED]>
To: "Rod Taylor" <[EMAIL PROTECTED]>; "Tom Lane" <[EMAIL PROTECTED]>
Cc: "Hackers List" <[EMAIL PROTECTED]>
Sent: Monday, May 13, 2002 12:12 AM
Subject: Re: [HACKERS] TRUNCATE
> > >From my
> "Rod Taylor" <[EMAIL PROTECTED]> writes:
> > Looks like CommentOperator goes to quite a bit of work (5 lines)
to
> > accomplish fetching the procedure and states specifically it's not
a
> > bug.
>
> I can see the value in having the function comme
Indeed...
Comment on operator adds the comment to the procedures, and drop
operator removes comments from pg_operator, leaving left over entries
in pg_description.
Looks like CommentOperator goes to quite a bit of work (5 lines) to
accomplish fetching the procedure and states specifically it's n
ys
liked:
The nonsubversion rule: If low-level access is permitted it should not
bypass security or integrity rules.
--
Rod
- Original Message -
From: "Joel Burton" <[EMAIL PROTECTED]>
To: "Tom Lane" <[EMAIL PROTECTED]>; "Rod Taylor" <[EMAIL PROTECTED]
simply drop all rules, foreign keys,
triggers, etc -- do the action -- re-apply constraints. Anything else
could mean their data isn't consistent.
--
Rod
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Rod Taylor" <[EMAIL PROTECTED]>
For my own protection I'm adding checks to truncate so that if there
is an ON DELETE trigger it will not execute the truncate command.
Anyway, should it really only be 'Disallow TRUNCATE on tables that are
involved in referential constraints'?
I'm thinking it should check for an on delete rule a
Doesn't appear that pg_sema is picking up the semaphore implementation
on FreeBSD.
bash-2.05a$ uname -a
FreeBSD knight.zort.ca 4.5-RELEASE FreeBSD 4.5-RELEASE #3: Sun Feb 3
22:26:40 EST 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/KNIGHT i386
In file included from ../../../../src/includ
I think the real trick is keeping track of the difference between:
begin;
ALTER TABLE tab ADD COLUMN col1 int4 DEFAULT 4;
commit;
and
begin;
ALTER TABLE tab ADD COLUMN col1;
ALTER TABLE tab ALTER COLUMN col1 SET DEFAULT 4;
commit;
The first should populate the column with the value of '4', the
> > I don't know about you, but I want PostgreSQL to be the best, be
THE most
> > reliable. Omitting "best" or "most" from the statement means that
we should
> > all just give up now, because PostgreSQL is pretty damn good
already.
>
> i think a mission statement full of boastfulness is just a sou
> INSERT INTO t1 (c1) VALUES (1), (2);
>
> would be executed in a similar fashion to:
>
> INSERT INTO t1 (c1) VALUES (1);
> INSERT INTO t1 (c1) VALUES (2);
>
> Does this sound reasonable?
I debated doing the above too. In fact, I had a partial
implementation at one point.
Howeve
I've run into an interesting issue. A very long running transaction
doing data loads is getting quite slow. I really don't want to break
up the transactions (and for now it's ok), but it makes me wonder what
exactly analyze counts.
Since dead, or yet to be visible tuples affect the plan that sh
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
> 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
> > There sure are a lot of arguments in the hackers list tho :) I do
wish
> > people would be a little less 'ad hominem' in their argument
styles,
> > however.
>
> Yes, things do get a little testy sometimes, and it does worry me,
but
> it seems to blow over quickly.
Bah.. You can't beat a good
Wrote a rather long message first time through. Anyway, basic problem
is the major tickmarks on the next release.
SMPng, KSEs, and various security overhauls are touching many portions
of the sourcecode in a single shot. Normal development since the
project started has been fairly isolated. So
Appears psql needs to know how to differentiate between it's own temp
tables and those of another connection. On the plus side, this takes
care of a TODO item to add temp table listings to psql.
Connection 1:
template1=# create temp table junk(col1 int4);
CREATE
template1=# select * from junk;
Ahh.. no wonder my aimless greps couldn't find anything.
I should just have read the BKI stuff ;)
Thanks
--
Rod
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
To: "Rod Taylor" <[EMAIL PROTECTED]>
Cc: "Hackers List" <[EMA
Just exactly how does one get an array into a system table?
Of course, _int2 and int2[] aren't normal C constructs so using it
within CATALOG won't work.
I suppose thats why the vector types were invented?
--
Rod
---(end of broadcast)---
TIP 4: D
> > The only problem with this is that I don't want the rename of a
> > constraint to have to fall over into the pg_depend table.
pg_depend
> > is currently happy with system OIDS or a Relation OID and some
unique
> > number to represent it -- much as pg_description wouldn't want to
know
> > the n
> Could we instead insist on a unique name per-table, and make this
table's
> key be (conrelid, conname)? Assigning a number seems quite
artificial.
The only problem with this is that I don't want the rename of a
constraint to have to fall over into the pg_depend table. pg_depend
is currently h
> > For tracking of Foreign Keys, Check constraints, and maybe NULL /
NOT
> > NULL (specific type of check constraint) I intend to create (as
per
> > suggestion) pg_constraint.
>
> Hmmm...I don't see the need at all for NOT NULL constraint tracking.
The
> spec doesn't seem to require it and we do
For tracking of Foreign Keys, Check constraints, and maybe NULL / NOT
NULL (specific type of check constraint) I intend to create (as per
suggestion) pg_constraint.
conrelid
conname
contype ('c'heck, 'f'oreign key, ???)
conkey (int2vector of columns of relid, like pg_index.indkey)
connum int4 --
> Haven't several people observed that the results from pgbench are
> very inconsistent? Perhaps some results from OSDB would be
worthwhile...
I've not looked very hard at OSDB. But it doesn't seem to run out of
the box.
> Based on that data, I'd vote against making any changes to
NAMEDATALEN.
Each test set has 3 time sets.
First is on pgbench -i (-s 5)
Second is on pgbench -t 3000 -s 5
Third is on postmaster during the run of the first 2.
The first test on a slow harddrive has a large effect for increasing the
namedatalen length.
Second through 4th sets don't really show any issue
Using current CVS (yesterday) I've rerun the benchmarks to see the
effects of various NAMEDATALEN settings.
3 times per setting.
First time is pgbench inserts (-s 5)
Second time is pgbench run (-t 3000 -s 5)
Third time is the postmaster during both of the above.
I'll run it again tonight on a
---
From: "Dave Page" <[EMAIL PROTECTED]>
To: "'Tom Lane'" <[EMAIL PROTECTED]>
Cc: "Rod Taylor" <[EMAIL PROTECTED]>; "Hackers List"
<[EMAIL PROTECTED]>
Sent: Sunday, April 21, 2002 2:49 PM
Subject: RE: [HACKERS] Really annoyin
> Having per-transaction command IDs might allow us to reduce the
range of
> the t_cmin and t_cmax fields. Unfortunately, probably by not all
that
> much, since one doesn't want to limit the number of commands within
a
> single transaction to something as silly as 65536.
If you can figure out how
> Of course, since Trigger on A depends on A we also have
> Trigger on A -> B.id
Should read:
Trigger on A -> relation A
Triggers depend on relation which owns it :)
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send a
In order to apply a dependency of foreign keys against a column set
the most obvious way to go is via the unique index which in turn
depends on the expected columns.
A(id) -> B(id)
A.id -> Foreign key -> Index on B.id -> B.id
If B.id is dropped it'll cascade forward.
The trick? Foreign keys
COMMENT ON DATABASE db IS 'Comment';
Now switch databases. Comment is gone.
Of course, adding the comments to template1 will carry comments
forward (in pg_description) to future DBs. Not fatal, but quite
annoying.
I suppose in order to add a comment field to pg_database it would need
to be to
> > Will we be able to accomplish the equivelent of the below?
>
> I think what you're depicting is the equivalent of a schema owner
> dropping a table in his schema, right? Yes, I proposed allowing
that,
Yes, thats what I was looking for. Sorry if I missed that in the
initial proposal.
> > Ye
> That is, of course, a BSD-ism that would confuse a lot of the SysV
people...
> :)
Yup.. But it's been around quite a while and I don't know of any
horrible problems with it -- that said I've not actually tried it on
OpenBSD (different mindset) but would be surprised if it wasn't the
same.
Sur
> I'm not real comfortable with this. The design I proposed is based
> fairly firmly on the Unix directory/file protection model --- which
> is assuredly not perfect, but it's survived a lot of use and is not
> known to have major flaws. You're suggesting that we should invent
Will we be able t
> > Another thing that would be needed to prevent users from creating
new
> > tables is to prevent them from creating schemas for themselves. I
am not
> > sure how to handle that --- should the right to create schemas be
treated
> > as a user property (a column of pg_shadow), or should it be
atta
> Should the owner of a database (assume he's not a superuser) have
the
> right to drop any schema in his database, even if he doesn't own it?
> I can see arguments either way on that one.
Given that you've chosen to allow the owner of a schema or the table
to drop a table, it would be consistent
).
--
Rod
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Rod Taylor" <[EMAIL PROTECTED]>
Cc: "Hackers List" <[EMAIL PROTECTED]>
Sent: Thursday, April 18, 2002 1:24 AM
Subject: Re: [HACKERS] [PATCHES] YADP - Yet another Dep
> 3. Isn't there a better way to find the initial dependencies? That
> SELECT is truly ugly, and more to the point is highly likely to
break
> anytime someone rearranges the catalogs. I'd like to see it
generated
> automatically (maybe using a tool like findoidjoins); or perhaps we
> could do th
The fact that an index exists adds a choice -- so by no means is the
index ignored.
But just because a Freeway exists across town doesn't make it faster
than the sideroads. It depends on the day of week, time of day, and
uncontrollable anomolies (accidents).
--
Rod Taylor
Your eyes are
Understood. It's not what I was expecting to happen.
Normally I always specifically state the match, so I was a little
surprised by the behaviour.
Makes sense to match the primary key and only the primary key though.
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel s
801 - 900 of 994 matches
Mail list logo
