It should also be noted that it's easy to get the DBAs to change their
username in the future when / if the @ hack goes away BUT it will be
difficult to change the usernames of the hundreds to thousands of
customer accounts.
For an upgrade, we'd end up making a script in the upgrade to keep them
On Tue, 2002-08-27 at 16:54, Bruce Momjian wrote:
I had an idea on this. It seems pretty pointless to show a query error
without a query, but some queries are very large.
How about if we print only the first 80 characters of the query, with
newlines, tabs, and spaces reduced to a single
A settable trim length would probably be a good idea, I suppose, for
those slinging 'bytea' and toasted texts around.
Yes, but the default should be NO TRIM or in 1K-4K range. IMHO
Ditto.
---(end of broadcast)---
TIP 1: subscribe and
Mostly because a user may explicitly create a database with wanted
permissions, only to have this 'special code' remove them.
I personally intend to immediately revoke permissions on public in
template1, to allow the database owner to grant them as needed.
On Mon, 2002-08-26 at 22:27, Bruce
a home.
---
Rod Taylor wrote:
Mostly because a user may explicitly create a database with wanted
permissions, only to have this 'special code' remove them.
I personally intend to immediately revoke permissions
On Wed, 2002-08-21 at 13:13, Bruce Momjian wrote:
Justin Clift wrote:
Bruce Momjian wrote:
Justin Clift wrote:
Only two things which have the potential to be worth waiting for, from
what I'm aware of. There may be others:
- Find out from Sir Mordred if he wants to take
On Wed, 2002-08-21 at 13:50, Marc G. Fournier wrote:
On Wed, 21 Aug 2002, Bruce Momjian wrote:
We learned a few lessons from previous releases. First, don't delay
the beta by days/weeks that drag on. Delay one month at a time.
Second, don't decide on a further delay the day before
Looks like the expected files weren't updated.
Probably my fault, but the tests themselves are fine.
On Tue, 2002-08-20 at 01:37, Neil Conway wrote:
The 'type_sanity' and 'domain' regression tests seem to fail with CVS
HEAD. Here's the diff:
*** ./expected/type_sanity.outSun Aug 4
On Tue, 2002-08-20 at 08:22, D'Arcy J.M. Cain wrote:
On August 19, 2002 11:58 pm, Rod Taylor wrote:
On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
The simple fix is to drop the money type entirely as it serves few
purposes -- but there are some who use it.
As the original
anyarraytype-- for array_eq, array_dims
Will this allow generic array iterator functions in the future?
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Tue, 2002-08-20 at 16:46, Zeugswetter Andreas SB SD wrote:
Hard to say what is good for those names imho, don't like
anytype :-(
How about any? It's a reserved word per SQL99, I think.
I would actually stick to opaque in that case, already used in other db's.
I want
On Mon, 2002-08-19 at 13:14, Florian Weimer wrote:
Justin Clift [EMAIL PROTECTED] writes:
You guys *definitely* write scarey code.
Yes, indeed. My code has a lot of unnecessary and error-prone input
validation checks because I don't trust the PostgreSQL parser.
Bah.. Check the datatype
On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
I'd like to see something done about this fairly soon, but it's not
happening for 7.3 ...
Hang on, you seem to be suggesting we release a major new upgrade, with
major new functionality, knowing it contains a way to trivially
On Sun, 2002-08-18 at 02:35, Joe Conway wrote:
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I agree 100%. If you want an index, unique constraint, or primary key on
a SERIAL, I think you should explicitly add it. SERIAL should give me a
column that automatically increments -- no
In MSSQL this
is gotten around by allowing the properties of the data type to be
altered, e.g. in MSSQL you can turn the IDENTITY property on or off
Rather pointless if it can be turned off, wouldn't you say?
What I would do if I wanted such a guarantee is to make insertions
go
# Disallow TRUNCATE on tables that are involved in referential
constraints
The above is on the TODO list. Are there any thoughts as to what we
want to do with this? The patch I submitted earlier received heavy
feedback saying it wasn't wanted due to rules and triggers (foreign
keys) being
I'd like to propose dropping the auto-creation of UNIQUE indexes on
serial columns for the following reasons:
1. Serials with indexes are quite difficult to handle in pg_dump. It
means that the implicitly created unique index must be destroyed prior
to loading the data, then re-created
n file included from fe-connect.c:24:
libpq-int.h:337: warning: `struct timeval' declared inside parameter
list
libpq-int.h:337: warning: its scope is only this definition or
declaration, which is probably not what you want.
fe-connect.c: In function `connectDBComplete':
fe-connect.c:1060:
On Sat, 2002-08-17 at 22:08, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am not seeing the failure here on BSD/OS. I just fixed the
libpq-int.h problem. Please update to cvs current and let me know what
you see.
FWIW, libpq seems to build fine here (HPUX 10.20) both
it.
---
Rod Taylor wrote:
On Sat, 2002-08-17 at 22:08, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am not seeing the failure here on BSD/OS. I just fixed the
libpq-int.h problem. Please update to cvs current and let me know what
you see.
FWIW, libpq seems
Is it possible for the cvs emails to include a URL to the appropriate
entries in cvs web?
The below is current:
Modified files:
src/backend/utils/adt: ruleutils.c
Is this possible?
Modified files:
But how many people would even use it? I can't see adding the bloat
unnecessarily and risking it accidently being turned on. Am I wrong
and really alot of people actually want/need this?
At an absolute minimum there are two. Myself and Marc.
That said, this is a semi-required step to
Yes, after updating docs to the newer DTD I intend to make them XML
compliant to ensure they work with v5 of docbook in the future.
Ah, an XML vs. SGML debate. I look forward to it.
This one is pretty simple. It's been announced that the docbook group
isn't looking to continue with
I have seen some negative reactions to the feature. I am willing to ask
for a vote, if that is what people want. If not, I will apply the patch
in the next day or two.
Please apply.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the
patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Rod Taylor wrote:
Appears there is a problem finding the opclass when indexing a domain
I'm going to vote for either @ or %.
On Wed, 2002-08-14 at 00:11, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I have no personal preference between period and @ or whatever. See if
you can get some other votes for @ because most left @ when the ORDER BY
idea came up from
On Wed, 2002-08-14 at 11:17, Ross J. Reedstrom wrote:
On Wed, Aug 14, 2002 at 09:39:06AM -0500, Greg Copeland wrote:
On Tue, 2002-08-13 at 23:43, Curt Sampson wrote:
Just my opinion of course, but I think it would be best to have a
detailed description of how everything in inheritance is
I believe the dictionary meaning of 'object' in this context would be 'a
cause for concern or attention'. Each of Peters uses of the word is
highly appropriate, as he was concerned and I'd agree with the
sentiments that those concepts needed attention.
Anyway, object with stars and strongly
On Wed, 2002-08-14 at 14:34, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Oh, so try it with and without. I can do that, but it seems more of a
security problem where you were trying two names instead of one. Do
people like that?
The nice thing about it is you can have any
Anyone mind if we bump the DTD version to Docbook 4.2?
This consists on all users who wish to build docs on installing the 4.2
DTD set, and updating some depreciated tags within the sgml files.
comment - remark
docinfo - appendixinfo, chapterinfo, bookinfo, etc.
What it buys is a number of
On Wed, 2002-08-14 at 16:32, Neil Conway wrote:
A couple questions regarding encrypted passwords:
(1) There was talk of changing the default value of the
'password_encryption' GUC variable for 7.3; AFAIK, this hasn't
happened yet. Should this be done?
Since ODBC is capable of using
On Wed, 2002-08-14 at 18:20, Bruce Momjian wrote:
Peter Eisentraut wrote:
I will vote against this as being a major loss of legibility. Perhaps
we could compromise on controlling it by a GUC variable, though.
I was afraid of that, but to pick up the theme of the day, I'm not sure if
Dependency - have pg_dump auto-create dependencies when loading 7.2.X
data?
Are we as far as we can go here?
The only trouble maker is foreign keys. If there was a nice way of
finding foreign keys in 7.2 and prior it probably would have been
implemented a long time ago in
On Thu, 2002-08-15 at 00:01, Christopher Kings-Lynne wrote:
Dependency - have pg_dump auto-create dependencies when
loading 7.2.X
data?
Are we as far as we can go here?
The only trouble maker is foreign keys. If there was a nice way of
finding foreign keys in 7.2 and
On Tue, 2002-08-13 at 02:47, Jeroen T. Vermeulen wrote:
On Mon, Aug 12, 2002 at 09:38:00PM -0300, Marc G. Fournier wrote:
should be fixed ... looks like just an ownership issue on a new directory
More like I uploaded that directory just as you were rsync'ing to
anonymous CVS and a
On Tue, 2002-08-13 at 07:49, Oleg Bartunov wrote:
We have a patch for pg_dump which adds a possibility to dump
a part of table, for example:
dump Top.Science.Astronomy heirarchy from dmoz catalog
pg_dump -d -t dmoz -w select * from dmoz where path @ 'Top.Science.Astronomy' dmoz
We
But I really seriously feel that this feature is a bad idea as presently
implemented. If necessary, I'll volunteer to change it the way I think
it should be (viz, initdb can set up a symlink to a specified xlog
directory; no change from previous behavior anywhere else).
Neither solution is
On Tue, 2002-08-13 at 11:11, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
I'm thinking that temporary views should be pretty trivial to
implement.
... except not so trivial, per the rest of your note.
Do we actually need any such feature? Views on temp tables already work
On Tue, 2002-08-13 at 12:22, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
I was playing with this a while back (when I had initially added CASCADE
to tables). I believe that in the event of a crash the temp tables are
not removed until their next use. This means that stale *real
On Tue, 2002-08-13 at 11:18, Bruce Momjian wrote:
Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
I'm thinking that temporary views should be pretty trivial to
implement.
... except not so trivial, per the rest of your note.
Do we actually need any such feature? Views
Tradeoffs, again ... What about emitting warnings after table drop
(easy)/creation (not so easy !) ?
The warnings are certainly there now. Dependency code won't let you do
such a thing without specifying CASCADE.
Hopefully CREATE OR REPLACE VIEW will be applied soon, which solves part
two
that TODO item was written before we had dependencies, and I think
it's obsolete. Basically the point of the TODO was to avoid
having broken views --- and we have solved that problem.
We may have broken views again when alter table drop column gets done
Any view depending on a column
Just go with tradition and label all of your variables with a
v_varname. Never use columns or tablenames prefixed with a v_.
It's a quick way for determining what is what. Forcing use of a prefix
in some places and not others would not be a nice thing -- especially as
the core takes on more
Maybe if some index had the indisclustered bit set one could select
that; but is it possible for some table to have more than one index with
it? Intuition (but no code observation) says no. And what happens with
those tables that do not have any such index?
The bool marker sounds useful.
All of that said, the cost of the check is so small it may save someones
ass some day when they have a corrupted catalog and the below
assumptions are no longer true.
On Mon, 2002-08-12 at 18:40, Greg Copeland wrote:
On Sun, 2002-08-11 at 21:15, Christopher Kings-Lynne wrote:
Not a problem.
Appears there is a problem finding the opclass when indexing a domain.
CREATE DOMAIN newint as int4;
CREATE TABLE tab (col newint unique);
ERROR: data type newint has no default operator class for access method
btree
You must specify an operator class for the index or define a
I intend to make 'serial' and 'serial8' domains of the int4 and int8
datatypes. Now they're regular types and columns in \d will be marked
as such. This leaves analyze.c to create the defaults but no longer
will it be doing any datatype conversions.
pg_dump and psql will be taught to ignore
P src/interfaces/libpqxx/configure.ac
cvs server: Updating src/interfaces/libpqxx/config
U src/interfaces/libpqxx/config/.cvsignore
cvs server: Updating src/interfaces/libpqxx/debian
cvs server: failed to create lock directory for
`/projects/cvsroot/interfaces/libpqxx/debian'
(/projects/cvsroot/interfaces/libpqxx/debian/#cvs.lock): Permission
denied
cvs server: failed to obtain dir lock in repository
`/projects/cvsroot/interfaces/libpqxx/debian'
cvs [server aborted]: read lock failed - giving up
I only just added that directory, so chances are you were
I think it buys the same as SERIAL does for sequences.
Is it likely to have more than one function using a complex type like
that? If not, then allowing it's creation (not enforcing) could be
useful.
On Fri, 2002-08-09 at 19:03, Joe Conway wrote:
Peter Eisentraut wrote:
Joe Conway writes:
Is it likely to have more than one function using a complex type like
that? If not, then allowing it's creation (not enforcing) could be
useful.
That's what I was thinking. In cases where you want to use the type for
several functions, use CREATE TYPE. If you only need the type for
http://developer.postgresql.org/docs/postgres/buildlog.html
It would appear that the files point to the old urls, not the new ones
as per the cvs segregation.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister
On Fri, 2002-08-02 at 13:53, Jeff Davis wrote:
Well, if you also have soundcard_products, in your example you could have a
product which is both a networkcard AND a soundcard. No way to restrict
that a product can be only one 'subclass' at a time... If you can make that
restriction using
An even more radical approach is to get rid of the hardwired index name
lists in indexing.h, and instead expect CatalogOpenIndices to make use
of the index OID lists that are maintained by the relcache (since 7.1 or
so). Then the typical call would reduce to
Perhaps I'm not remembering correctly, but don't SQL functions still
have an abnormally high cost of execution compared to plpgsql?
Want to try the same thing with a plpgsql function?
On Thu, 2002-08-01 at 18:23, Neil Conway wrote:
Ok, here are some crude benchmarks to attempt to measure
On Thu, 2002-08-01 at 00:42, Stephen Deasey wrote:
Neil Conway said:
FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?
Until someone takes the time to determine what the performance
implications of this change will be, I don't think we should
change this. Given that no one
On Thu, 2002-08-01 at 10:44, Neil Conway wrote:
On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote:
Is there some common convention of names?
functions. However, establishing a naming convention without
breaking backwards compatibility might be tricky.
Supporting both names for a
On Thu, 2002-08-01 at 15:33, Vince Vielhaber wrote:
On Thu, 1 Aug 2002, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
... is once more 'normal' ...
Uh, it's completely broken as far as I can tell.
$ pwd
/home/postgres/pgsql/src/bin/pg_dump
$ cvs status
cvs
Another idea is to change pg_hba.conf to not default to 'trust' but then
the installing user is going to have to choose a password.
I like this approach. Set it to password (or md5) on local, and force
the request of a password during initdb.
If for some reason they forget their password,
As an implementor I'm always wary of using features nobody else has,
especially in databases. So, if I'd want postgres to have one thing
nobody else has, it would be the most complete standard SQL
implementation - so it would at least be the other products' fault if
I'd have to do any
Given the GPL isn't wanted in the contrib directory, it may be wise to
take care of src/interfaces/odbc/license.txt
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
The current ODBC drivers on the website don't appear to work with recent
development.
I'm able to login, but immediately after it throws the error 'Blank'
with a large negative number above (-2^16 or so).
I don't have Visual C, so would it be possible for someone to build a
new (working)
-Original Message-
From: Rod Taylor [mailto:[EMAIL PROTECTED]]
Sent: 29 July 2002 14:39
To: PostgreSQL-development
Subject: [HACKERS] GPL License
Given the GPL isn't wanted in the contrib directory, it may
be wise to take care of src/interfaces/odbc/license.txt
Try this:
SELECT count(*)
FROM (
SELECT count(*)
FROM test
GROUP BY date_trunc('day', test_date)
) as qry;
On Fri, 2002-07-26 at 16:03, Yuva Chandolu wrote:
Hi,
We have a query select count(count(*)) from test group by
trunc(test_date). This works fine
On Fri, 2002-07-26 at 12:55, Marc G. Fournier wrote:
On Fri, 26 Jul 2002, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
This still doesn't allow john on db1 to be a different user than john on
db2. To accomplish that (easily) we still need to install different
instances
On Wed, 2002-07-24 at 02:22, Marc Lavergne wrote:
I have a need for relation synonyms in PostgreSQL. I don't see it in
7.2.1 but the catalog seems to be able to support it more or less.
Here's what I intend to do:
1) Create a duplicate record in pg_class for the base table information
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 than EXECUTE
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, for any
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
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're
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
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
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?
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
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 function to have it's own schema as
pre-pended
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 very easily.
Would it be appropriate for the function
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 didn't like the way you did
that, and was trying
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?
I was looking to encourage users to use core SQL as I spend
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
* 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
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
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
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 who
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 triggers.
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 dump
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
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):
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?
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 the
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
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 am
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 memory, and I do
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
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
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
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 again ...
I
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 large enough
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 understand a
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
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, at the moment
701 - 800 of 934 matches
Mail list logo
