> > For example you want to define a function for LATIN1 to UNICODE conversion
> > function would look like:
> >
> > function_for_LATIN1_to_UTF-8(from_string opaque, to_string opaque, length
> > integer)
> > {
> > :
> > :
> > generic_function_using_iconv(from_str, to_str, "ISO-8859-1"
I think that we are getting into two or three issues here. If I may:
(1) Is DROP TABLE acceptable by the standard?
(2) Should we break "old" functionality?
(3) assuming we support the old syntax:
should DROP TABLE be functionally the same as
On Wed, 10 Jul 2002, Tom Lane wrote:
> As I currently have Rod's dependency code set up, an index derived from
> a UNIQUE or PRIMARY KEY clause can't be dropped directly; you must drop
> the constraint instead.
> ...
> I went out of my way to make the above happen, but now I'm wondering if
> it w
As I currently have Rod's dependency code set up, an index derived from
a UNIQUE or PRIMARY KEY clause can't be dropped directly; you must drop
the constraint instead. For example:
regression=# create table foo (f1 text primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Sounds good to me, and I don't think we need to require RESTRICT just
> > because the standard says so. Does the standard require RESTRICT for
> > every DROP or just drops that have foreign keys?
>
> Syntactically, it requires RESTR
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Sounds good to me, and I don't think we need to require RESTRICT just
> because the standard says so. Does the standard require RESTRICT for
> every DROP or just drops that have foreign keys?
Syntactically, it requires RESTRICT or CASCADE on *every* fo
> > As far as this question, seems with no RESTRICT/CASCADE, it fails, with
> > RESTRICT it drops the trigger, and with CASCADE it drops the referencing
> > table. Is that accurate?
>
> Not at all. CASCADE would drop the foreign key constraint (including
> the triggers that implement it), but no
On Wed, 10 Jul 2002, Tom Lane wrote:
> Bradley Baetz <[EMAIL PROTECTED]> writes:
> > I'm referring to the mysql |timestamp| type, which will update that
> > column's contents to |now()| when any UPDATE is given for that partcular
> > row, unless the column was assigned to. I don't know how to han
Bradley Baetz <[EMAIL PROTECTED]> writes:
> I'm referring to the mysql |timestamp| type, which will update that
> column's contents to |now()| when any UPDATE is given for that partcular
> row, unless the column was assigned to. I don't know how to handle the
> last part in a trigger.
It'd probab
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > As far as this question, seems with no RESTRICT/CASCADE, it fails, with
> > RESTRICT it drops the trigger, and with CASCADE it drops the referencing
> > table. Is that accurate?
>
> Not at all. CASCADE would drop the foreign key co
Bruce Momjian <[EMAIL PROTECTED]> writes:
> As far as this question, seems with no RESTRICT/CASCADE, it fails, with
> RESTRICT it drops the trigger, and with CASCADE it drops the referencing
> table. Is that accurate?
Not at all. CASCADE would drop the foreign key constraint (including
the trig
On Thu, 11 Jul 2002, Christopher Kings-Lynne wrote:
> Of course, you might have thought about the correct column types in advance,
> but hey :) I think that there's no way to have a rollback-able column type
> change without temporarily doubling space. Actually, I think Oracle has
> some sort o
"Groff, Dana" <[EMAIL PROTECTED]> writes:
> Actually, the answer is even clearer, the standard calls for the specification
> of "CASCADE" or "RESTRICT" and doesn't support _not_ having that specified.
> (the is NOT [drop behavior] aka optional)
Right, the spec does not allow it to be defaulted.
On 10 Jul 2002, Rod Taylor wrote:
> enum(A,B,C) -> column char(1) check (column IN ('A', 'B', 'C'))
right.
>
> timestamp? Output pattern may be different, but PostgreSQL 7.3 will
> accept any timestamp I've thrown at it. Lots of weird and wonderful
> forms.
I'm referring to the mysql |times
Jan Wieck wrote:
> Tom Lane wrote:
> >
> > Stephan Szabo <[EMAIL PROTECTED]> writes:
> > > On Wed, 10 Jul 2002, Tom Lane wrote:
> > >> DROP TABLE foo RESTRICT;
> > >>
> > >> Should this succeed? Or should it be necessary to say DROP CASCADE to
> > >> get rid of the foreign-key reference to foo?
> Tom Lane wrote:
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > > Just a test to make sure both are being used properly ... should help
> > > increase overall list speeds ...
> >
> > Things do seem to be *markedly* faster today than a few days ago.
> > Good work!
>
> Yea, but how come m
[EMAIL PROTECTED] (Bruce Momjian) wrote:
> Lamar Owen wrote:
>> If you doubt that fact, you need to read the archives for awhile to
>> get a sense of how this project is organized. If the steering
>> committee (the core six) decide against something, then that
>> something _does_not_happen_. End
Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Just a test to make sure both are being used properly ... should help
> > increase overall list speeds ...
>
> Things do seem to be *markedly* faster today than a few days ago.
> Good work!
Yea, but how come my email box is fil
Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Just a test to make sure both are being used properly ... should help
> > increase overall list speeds ...
>
> Things do seem to be *markedly* faster today than a few days ago.
> Good work!
--
Bruce Momjian
On Wed, 10 Jul 2002, Tom Lane wrote:
> CREATE TABLE foo (f1 int primary key);
> CREATE TABLE bar (f1 int references foo);
> DROP TABLE foo RESTRICT;
>
> Should this succeed? Or should it be necessary to say DROP CASCADE to
> get rid of the foreign-key reference to foo?
>
> Our
> > > 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
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > I think the idea was to have it default to CASCADE for this release, not
> > to break existing code right away.
>
> I never thought that. If we default to CASCADE then a DROP is likely to
> delete stuff that it would not have deleted in prior releases.
Jan Wieck <[EMAIL PROTECTED]> writes:
> I think the idea was to have it default to CASCADE for this release, not
> to break existing code right away.
I never thought that. If we default to CASCADE then a DROP is likely to
delete stuff that it would not have deleted in prior releases. That
seems
> > 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
> > 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 change the bz schema.
>
> DROP COLUMNS should be
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 change the bz schema.
DROP COLUM
Rod Taylor wrote:
>
> > 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 kn
On 10 Jul 2002, Rod Taylor wrote:
> > 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
> 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
Actually, the answer is even clearer, the standard calls for the specification
of "CASCADE" or "RESTRICT" and doesn't support _not_ having that specified.
(the is NOT [drop behavior] aka optional)
NOTE: ::= CASCADE | RESTRICT
as defined in 11.2
Dana
PS to be complete: all these references ar
IMHO, I believe that the standard should be adhered to if at all possible.
Since Cascade was added, Restrict must be the default is my reading of the
standard.
So that everyone can talk from the same sheet, the 1999 SQL Standard for DROP
TABLE follows:
11.20
Function
Destroy a table.
Format
:
On 10 Jul 2002, Rod Taylor wrote:
> 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
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
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 change the bz schema.
See
http://lxr.mozilla.org/mozilla/source/
Tom Lane wrote:
>
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Wed, 10 Jul 2002, Tom Lane wrote:
> >> DROP TABLE foo RESTRICT;
> >>
> >> Should this succeed? Or should it be necessary to say DROP CASCADE to
> >> get rid of the foreign-key reference to foo?
>
> > I think the above should f
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
On Wed, 10 Jul 2002, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Wed, 10 Jul 2002, Tom Lane wrote:
> >> DROP TABLE foo RESTRICT;
> >>
> >> Should this succeed? Or should it be necessary to say DROP CASCADE to
> >> get rid of the foreign-key reference to foo?
>
> > I think
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Just a test to make sure both are being used properly ... should help
> increase overall list speeds ...
Things do seem to be *markedly* faster today than a few days ago.
Good work!
regards, tom lane
--
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 10 Jul 2002, Tom Lane wrote:
>> DROP TABLE foo RESTRICT;
>>
>> Should this succeed? Or should it be necessary to say DROP CASCADE to
>> get rid of the foreign-key reference to foo?
> I think the above should fail. If someone was adding restri
On Wed, 10 Jul 2002, Tom Lane wrote:
> Consider
>
> CREATE TABLE foo (f1 int primary key);
>
> CREATE TABLE bar (f1 int references foo);
>
> DROP TABLE foo RESTRICT;
>
> Should this succeed? Or should it be necessary to say DROP CASCADE to
> get rid of the foreign-key reference
Consider
CREATE TABLE foo (f1 int primary key);
CREATE TABLE bar (f1 int references foo);
DROP TABLE foo RESTRICT;
Should this succeed? Or should it be necessary to say DROP CASCADE to
get rid of the foreign-key reference to foo?
Our historical behavior is to allow th
On Wednesday 10 July 2002 04:42 pm, Jan Wieck wrote:
> Lamar Owen wrote:
> > On Wednesday 10 July 2002 03:24 am, Jan Wieck wrote:
> > > The problem why this conflicts with these package managers is,
> > > because they work package per package, instead of looking at the
> > > big picture. Who said
On Wed, Jul 10, 2002 at 11:15:59PM +0200, Iavor Raytchev wrote:
> Hello,
>
> Is there a proper 'powered by postgresql' .gif or something?
Try
http://www.pgsql.com/propaganda/
A
--
Andrew Sullivan 87 Mowat Avenue
Liberty RMS
Hello,
Is there a proper 'powered by postgresql' .gif or something?
Can't find anything like this.
Iavor
--
Iavor Raytchev
very small technologies (a company of CEE Solutions)
in case of emergency -
call: + 43 676 639 46 49
or write to: [EMAIL PROTECTED]
www.verysmall.org
-
Lamar Owen wrote:
> On Wednesday 10 July 2002 03:24 am, Jan Wieck wrote:
>
> > The problem why this conflicts with these package managers is,
> > because they work package per package, instead of looking at the
> > big picture. Who said you can replace package A before running
> > the pre-upgrad
Just a test to make sure both are being used properly ... should help
increase overall list speeds ...
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
On Wednesday 10 July 2002 10:26 am, Hannu Krosing wrote:
> Actually, if the python dumper can be made to work somewhat reiably it
> can be run after install/upgrade without too much trouble.
Yes, yes, of course. My bad -- brain needs oil change... :-)
Thanks for the links to the python stuff, p
Iavor Raytchev wrote:
>
> Hello everybody,
>
> I want to apologise for inflating all lists (as Chris noticed) with
> insignificant discussions. I would like to invite all pgaccess involved
> people to restrict their postings to [EMAIL PROTECTED], unless there
> is a good reason for doing it diff
Hello everybody,
I want to apologise for inflating all lists (as Chris noticed) with
insignificant discussions. I would like to invite all pgaccess involved
people to restrict their postings to [EMAIL PROTECTED], unless there
is a good reason for doing it differently.
Thanks,
Iavor
PS I get th
On Wed, 2002-07-10 at 19:56, Lamar Owen wrote:
> On Wednesday 10 July 2002 11:48 am, Hannu Krosing wrote:
> > On Wed, 2002-07-10 at 16:20, Lamar Owen wrote:
> > > On Wednesday 10 July 2002 09:11 am, Hannu Krosing wrote:
> > > > And I have written custom postgres table dumpers in python without too
Iavor,
> Any other suggestions?
I can tell you from experience that Double-Choco-Latte, another
PHP/PostgreSQL tool, is really set up just for single projects. So it
would work fine for PGAccess-only. However, DCL has its own problems
and is not necessarily better than Mozilla; I personally d
On Wed, 2002-07-10 at 21:49, Iavor Raytchev wrote:
> Josh Berkus said:
> > Iavor,
> >
> >> Any other suggestions?
> >
> > I can tell you from experience that Double-Choco-Latte, another
> > PHP/PostgreSQL tool, is really set up just for single projects. So it
> > would work fine for PGAccess-only
Josh Berkus said:
> Iavor,
>
>> Any other suggestions?
>
> I can tell you from experience that Double-Choco-Latte, another
> PHP/PostgreSQL tool, is really set up just for single projects. So it
> would work fine for PGAccess-only. However, DCL has its own problems
> and is not necessarily bett
On Wednesday 10 July 2002 11:48 am, Hannu Krosing wrote:
> On Wed, 2002-07-10 at 16:20, Lamar Owen wrote:
> > On Wednesday 10 July 2002 09:11 am, Hannu Krosing wrote:
> > > And I have written custom postgres table dumpers in python without too
> > > much effort (except reverse-engineering the page
On Wed, 2002-07-10 at 16:20, Lamar Owen wrote:
> On Wednesday 10 July 2002 09:11 am, Hannu Krosing wrote:
>
> > The only problem with this approach is that it needs maintaining
> > separately from postgres proper. OTOH, this may also be a good thing, as
> > a separate reimplementation is only kno
On Wed, 2002-07-10 at 16:15, Lamar Owen wrote:
> [cc: trimmed]
>
> On Wednesday 10 July 2002 03:42 am, Jan Wieck wrote:
> >How many rewrite rules have to be converted into
> > the new parsetree format during an RPM upgrade?
>
> Don't know if anything comparable exists.
>
IMHO the best solution
On Wed, 2002-07-10 at 16:20, Lamar Owen wrote:
> On Wednesday 10 July 2002 09:11 am, Hannu Krosing wrote:
> > On Wed, 2002-07-10 at 01:09, Lamar Owen wrote:
> > > The wc utility isn't in the path in an OS install situation. The df
> > > utility isn't in the path, either. You can use python, thou
On Wednesday 10 July 2002 09:11 am, Hannu Krosing wrote:
> On Wed, 2002-07-10 at 01:09, Lamar Owen wrote:
> > The wc utility isn't in the path in an OS install situation. The df
> > utility isn't in the path, either. You can use python, though. :-) Not
> > that that would be a good thing in thi
[cc: trimmed]
On Wednesday 10 July 2002 03:42 am, Jan Wieck wrote:
> Lamar Owen wrote:
> > As a note of interest, RPM itself is backed by a database, db3. Prior to
> > version 4.x, it was backed by db1. Upgrading between the versions of RPM
> > is simply -- installing db3 and dependenies, upgra
On Wednesday 10 July 2002 03:24 am, Jan Wieck wrote:
> Oliver Elphick wrote:
> > The current upgrade process for PostgreSQL is founded on the idea that
> > people build from source. With binary distributions, half the users
> > wouldn't know what to do with source; they expect (and are entitled t
On Wed, 2002-07-10 at 01: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
> > Just out of curiosity, what database is backing it?
> >
> > If it isn't PostgreSQL, what about using PHP BugTracker instead? That
> > runs on top of PostgreSQL.
> >
> > http://sourceforge.net/projects/phpbt/
> >
> >
> > Jan
>
>
> Or Gborg... ;-)
>
> http://gborg.postgresql.org/project/g
Lamar Owen wrote:
>
> [replying to myself]
> On Tuesday 09 July 2002 07:34 pm, Lamar Owen wrote:
> > if you do this. Already RPM can rollback the transaction being done on the
> > RPM database (it's a db3 database system), but rolling back the filesystem
> > is a little different.
>
> As a note
Oliver Elphick wrote:
>
> The current upgrade process for PostgreSQL is founded on the idea that
> people build from source. With binary distributions, half the users
> wouldn't know what to do with source; they expect (and are entitled to
> expect) that an upgrade will progress without the need
64 matches
Mail list logo
