Deep copy with User defined data types sometimes get a little
wild, possibly with alignment and memory context. For example
a UDT which is a char followed by an int might be tricky to recognize
that alignment might be needed. It might even be better to have
the UDT writer write their own dee
Neil,
> Unless anyone sees a problem with this, I'll work on this. I
> definately think it's inappropriate for 7.3.1 though.
Thank you!
-Josh Berkus
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/use
Neil Conway wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
> > Doesn't seem like kill's exit code is going to tell you enough.
> > If you got, say, "Permission denied" rather than "No such process",
> > you shouldn't report that the postmaster isn't running.
>
> Ok, fair enough -- so is there any w
Tom Lane <[EMAIL PROTECTED]> writes:
> Doesn't seem like kill's exit code is going to tell you enough.
> If you got, say, "Permission denied" rather than "No such process",
> you shouldn't report that the postmaster isn't running.
Ok, fair enough -- so is there any way to improve this behavior?
C
Neil Conway <[EMAIL PROTECTED]> writes:
> After an unclean shutdown (e.g. a kernel crash), pg_ctl isn't smart
> enough to realize that it won't be able to successfully shut down the
> postmaster:
> $ pg_ctl -D /pgsql/data stop
> /pgsql/bin/pg_ctl: line 269: kill: (2039) - No such process
> waiting
Josh Berkus <[EMAIL PROTECTED]> writes:
> create or replace function rowtype_test ()
> returns text as '
> declare this_row candidates%rowtype;
> that_row candidates%rowtype;
> begin
> select * into this_row
> from candidates;
>
> that_row := this_row;
>
> return that_row.first_name;
>
> e
After an unclean shutdown (e.g. a kernel crash), pg_ctl isn't smart
enough to realize that it won't be able to successfully shut down the
postmaster:
$ pg_ctl -D /pgsql/data stop
/pgsql/bin/pg_ctl: line 269: kill: (2039) - No such process
waiting for postmaster to shut
down...
Mark Le Huray <[EMAIL PROTECTED]> writes:
> - create sequence autonumber increment 1 minvalue 0 start 0;
> - create table testtable1 ( pk int primary key );
> - create table testtable2 ( fk int primary key references
> testtable1(pk));
> - create rule updatetesttable2 as on insert to testtable1 do
Reto Stamm <[EMAIL PROTECTED]> writes:
> When I have a sequence like this:
> CREATE SEQUENCE "test_id_seq" start -32768 increment 1 maxvalue 32767 minvalue
> -32768 cache 1;
> it will show up in schema.txt like this:
> CREATE SEQUENCE "test_id_seq" start 1 increment 1 maxvalue 32767 minvalue -327
On 5 Nov 2002, Mark Le Huray wrote:
> Apologies if this bug has already been reported and I am also reasonably
> new to postgresql so I might be doing something stupid :-)
>
> Anyway to replicate the problem:
>
> Initial tables:
>
> - create sequence autonumber increment 1 minvalue 0 start 0;
> -
Bug: Cannot assign ROWTYPE, RECORD variables in PL/pgSQL
Affects: PL/pgSQL
Severity: Annoyance
Priority: Minor Enhancement
Confirmed On: 7.3beta2, Linux
Given the following function:
===
create or replace function rowtype_test ()
returns text as '
declare this
Lars <[EMAIL PROTECTED]> writes:
> Is that expected behavior in 7.3?
It is if you initdb'd in a locale other than "C". Use pg_controldata
to check.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe
Hi,
When I have a sequence like this:
CREATE SEQUENCE "test_id_seq" start -32768 increment 1 maxvalue 32767 minvalue
-32768 cache 1;
and dump it using
pg_dump -s -c -f schema.txt testdb
it will show up in schema.txt like this:
CREATE SEQUENCE "test_id_seq" start 1 increment 1 maxvalue 32767
Apologies if this bug has already been reported and I am also reasonably
new to postgresql so I might be doing something stupid :-)
Anyway to replicate the problem:
Initial tables:
- create sequence autonumber increment 1 minvalue 0 start 0;
- create table testtable1 ( pk int primary key );
- cr
John Lim ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Using || with char and char varying
Long Description
The following sql:
select firstname||lastname from adoxyz;
generates this error:
PostgreSQL said: ERROR: Unable t
I have a table with a bunch of varchar columns.
In 7.2.3 Postgres would indexes on varchar column
for certain like queries.
This is a script from 7.2.3:
lars=> \d agency
Table "agency"
Column | Type | Modifiers
-+--
16 matches
Mail list logo
