> -Original Message-
>
> That's exactly the error you'd get on a pre-8.0 system that doesn't
> support altering a column's type. Are you looking at 8.0
> documentation
> but running a 7.x server? What does "SELECT version();" show?
Yes, that's it. I am looking into an 8.0 doc while
Thank you for this rather detailed example.
I already learned something and omitted a fault. There should be enogh to
implement such a Queue. :-)
> -Original Message-
> From: Andrew Hammond [mailto:[EMAIL PROTECTED]
> Sent: Mittwoch, 12. Jänner 2005 17:19
> To: KÖPFERL Robert
> Cc: 'pgsq
KÖPFERL Robert wrote:
>I'm a little bit perplexed now... is it really the case that pre 8.0 systems
>aren't able to change col-types?
I would guess that the column type altering code is just short hand
for creating a new column of the correct type, copying the old column
into the new one, deleting
I'm working with a quite flat table schema (think: mySQL ;)),
and I want to divide it into two tables.
Lets start with how it looks now:
CREATE TABLE old_table (
id serial PRIMARY KEY,
body text,
path_a varchar(1024),
gendate_a date,
path_bb varchar(1024),
gendate_bb date,
path_ccc v
On Thu, 13 Jan 2005 11:26:04 +0100, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
> I can write:
>
> SELECT * FROM (SELECT id, path AS path_a FROM new_table_paths WHERE id
> = <> AND pathtype = 'a') AS a NATURAL FULL OUTER JOIN (SELECT id,
> path AS path_bb FROM new_table_paths WHERE id = <> AND patht
The first seems like an appropriate solution. Fireing a trigger-function
that returns null.
If I however try to implement a function getnull in sql I fail. Defining the
trigger requests a function of type trigger while definition of a function
forbids using trigger as return type. So RTFM - there's
On Thu, 13 Jan 2005 11:45:52 +0100, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
> > SELECT * FROM (SELECT id, path AS path_a FROM new_table_paths WHERE
> > pathtype = 'a') AS a NATURAL FULL OUTER JOIN (SELECT id, path AS
> > path_bb FROM new_table_paths WHERE pathtype = 'bb') AS bb WHERE id =
> > <>;
On Thu, Jan 13, 2005 at 09:48:02AM +0100, KÖPFERL Robert wrote:
> I'm a little bit perplexed now... is it really the case that pre 8.0 systems
> aren't able to change col-types?
It really is. In fact, the feature was (IIRC) somewhat
controversial, because there are all sorts of decisions that ne
>
> It really is. In fact, the feature was (IIRC) somewhat
> controversial, because there are all sorts of decisions that need to
> be made about what to do with incompatible types. What if you change
> from int8 to int4? What about varchar(4) to char(4)? Just to name
> two simple-minded exa
On Thu, Jan 13, 2005 at 01:30:21PM +0100, KÖPFERL Robert wrote:
> but that's the reason, the USING clause exists. It however still remains a
Right. Please see the archives about how this was hammered out.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
A certain description of men are for getting o
Hi,
suppose I have a let's say heavy used table. There's a column containing
UNIQUE in4
values. The data type musn't exceed 32-Bit. Since however the table is heavy
used 2^32 will be reached soon and then? There are far less than 4G-records
saved thus these values may be reused. How can this be ac
On Thu, Jan 13, 2005 at 06:08:20PM +0100, KÖPFERL Robert wrote:
> Hi,
>
> suppose I have a let's say heavy used table. There's a column containing
> UNIQUE in4
> values. The data type musn't exceed 32-Bit. Since however the table is heavy
> used 2^32 will be reached soon and then? There are far le
On Thu, Jan 13, 2005 at 18:08:20 +0100,
KÖPFERL Robert <[EMAIL PROTECTED]> wrote:
> Hi,
>
> suppose I have a let's say heavy used table. There's a column containing
> UNIQUE in4
> values. The data type musn't exceed 32-Bit. Since however the table is heavy
> used 2^32 will be reached soon and th
On Thu, 2005-01-13 at 11:08, KÃPFERL Robert wrote:
> Hi,
>
> suppose I have a let's say heavy used table. There's a column containing
> UNIQUE in4
> values. The data type musn't exceed 32-Bit. Since however the table is heavy
> used 2^32 will be reached soon and then? There are far less than 4G-re
On Thu, Jan 13, 2005 at 02:48:47PM -0600, Scott Marlowe wrote:
> On Thu, 2005-01-13 at 11:08, KÖPFERL Robert wrote:
> > suppose I have a let's say heavy used table. There's a column containing
> > UNIQUE in4
> > values. The data type musn't exceed 32-Bit. Since however the table is heavy
> > used
On Thu, 2005-01-13 at 15:19, Michael Fuhr wrote:
> On Thu, Jan 13, 2005 at 02:48:47PM -0600, Scott Marlowe wrote:
> > On Thu, 2005-01-13 at 11:08, KÃPFERL Robert wrote:
>
> > > suppose I have a let's say heavy used table. There's a column containing
> > > UNIQUE in4
> > > values. The data type mus
On Thu, Jan 13, 2005 at 03:31:54PM -0600, Scott Marlowe wrote:
> Any method that tries to reuse sequence numbers is a bad idea (TM) and
Why? I can think of a dozen cases where it can be useful. It just
depends on the application.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future this sp
On Thu, Jan 13, 2005 at 03:31:54PM -0600, Scott Marlowe wrote:
>
> I wasn't sure if that was a limitation he was facing due to business
> rules or if he was referring to the limit in postgresql.
Gotcha -- I should have asked about the nature of the requirement.
--
Michael Fuhr
http://www.fuhr.o
On Thu, 2005-01-13 at 15:43, Andrew Sullivan wrote:
> On Thu, Jan 13, 2005 at 03:31:54PM -0600, Scott Marlowe wrote:
> > Any method that tries to reuse sequence numbers is a bad idea (TM) and
>
> Why? I can think of a dozen cases where it can be useful. It just
> depends on the application.
The
On Thu, Jan 13, 2005 at 03:57:04PM -0600, Scott Marlowe wrote:
> What cases are you thinking of? I've seen some very limited ones, like
Off the top of my head
- legacy application, closed, where you can't fix the source and can't
have larger than 32bit datatype, but you have another way to ensur
You could update all the fields which use this sequence number. You say
you have a lot of activity so you must have mahy holes in your sequence,
probably of the possible 2^32 values, only a fes millions are used.
You can do the following :
- Take down the database, back it up, and re
Title: pgmirror
Hi,
I need some help getting dbMirror working. I have installed the contrib RPM package for Redhat Linux. However it hasn't copied all the necessary files for dbMirror. I could only find pending.so.
I have tried coping the other files from : http://develop
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> You can set the sequence up to cycle (so once it gets to the end, it
> wraps around to the beginning again). The keyword is CYCLE at CREATE
> SEQUENCE time. It defaults to NO CYCLE.
>
> One potential problem, of course, are collisions on the table,
23 matches
Mail list logo
