Dustin Sallings <[EMAIL PROTECTED]> writes:
> Around 18:51 on Dec 1, 2002, Tom Lane said:
> # I can't reproduce it either (and I just finished trying it on OS X
> # 10.2.2, so it's not just a matter of a platform dependency).
> #
> # Dustin, we really need more info to proceed any further. How abo
I will send the bug report copying what is said here
to Apple.
I copied and pasted the error message here so it did
not say 'en_US'.
Ted
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> Theodore Petrosky <[EMAIL PROTECTED]> writes:
> > I've just finished the install of 7.3 release on
> mac
> > OSX 10.
Hi,all
I encounter a serious problem. I have made postmaster(7.3b5) run as a service in Win2k using cygrunsrv. But everytime I shutdown windows properly and then start it.postmaster service cannot start . It leave a postmaster.pid in the data directory and ipc cannot be realeased properly . I ha
Rod Taylor <[EMAIL PROTECTED]> writes:
> The second, adddepend.patch is what should be applied to the
> contrib/adddepend/adddepend file
Roger. Patch applied in both HEAD and REL7_3_STABLE branches.
regards, tom lane
---(end of broadcast)-
On Sun, 2002-12-01 at 18:57, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Adams patch is good. Please apply when you find time.
>
> I'm a bit confused by the patch --- it has a patch against "upgrade.pl"
> which is not to be seen in contrib/adddepend. What's up with that?
It see
elein <[EMAIL PROTECTED]> writes:
> I think I do not know the background on this.
I think it's mostly historical. The one-byte "char" datatype seems to
date back to Berkeley days, long before there was any concern for SQL
compliance (it's there in Postgres 4.2). "bpchar" was apparently added
in
I think I do not know the background on this.
Could you explain why the char type is converted
to bpchar when a function is defined to return a char?
Are only C functions affected? Is char as a type deprecated
in favor of bpchar? Should something in the fmgr interface
change to support this?
Adam Buraczewski <[EMAIL PROTECTED]> writes:
> And the name of the script was changed from original upgrade.pl to
> adddepend, of course.
Oh, I see. Looks like the README didn't get fixed for that change :-(
Will take care of it.
regards, tom lane
---
On Sun, Dec 01, 2002 at 06:57:25PM -0500, Tom Lane wrote:
> I'm a bit confused by the patch --- it has a patch against "upgrade.pl"
> which is not to be seen in contrib/adddepend. What's up with that?
I attached _two_ patches to my first posting -- one for upgrade.pl and
one for adddepend. Both
Rod Taylor <[EMAIL PROTECTED]> writes:
> Adams patch is good. Please apply when you find time.
I'm a bit confused by the patch --- it has a patch against "upgrade.pl"
which is not to be seen in contrib/adddepend. What's up with that?
regards, tom lane
--
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I just tried:
> test=> alter user postgres set search_path to 'public';
> ALTER USER
> test=> alter user postgres set search_path to default;
> ALTER USER
> and it worked fine here. This is with current CVS. Can anyone else
> rep
Theodore Petrosky <[EMAIL PROTECTED]> writes:
> I've just finished the install of 7.3 release on mac
> OSX 10.2.2. I notice that initdb will permit me to
> init a directory for use, then when running postmaster
> using the directory I get a fatal error:
> FATAL: invalid value for option 'LC_TIME'
[EMAIL PROTECTED] writes:
> I have a table that has a delete rule that performs a logical delete (set a
>``deleted'' column to true) whenever deletes occur on the table. Prior to 7.3,
>delete would report the update count, but as of 7.3, delete reports 0 rows were
>deleted.
We did rejigger the
[EMAIL PROTECTED] writes:
> 7.3 - timespan missing?
timespan's been deprecated since 7.0, and is now gone entirely. Use
interval (which is what it was an alias for).
regards, tom lane
---(end of broadcast)---
TIP 1: subscri
I just tried:
test=> alter user postgres set search_path to 'public';
ALTER USER
test=> alter user postgres set search_path to default;
ALTER USER
and it worked fine here. This is with current CVS. Can anyone else
reproduce the problem?
On Sun, 2002-12-01 at 17:03, Dustin Sallings wrote:
> Around 16:54 on Dec 1, 2002, Neil Conway said:
>
> # Works for me:
>
> Well that's unfortunate, it crashes consistently for me.
Heh, ok. I thought my post implied "given the information you've given
me, I can't reproduce the bug, so can
Dustin Sallings ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
delete rule reports 0 modifications
Long Description
I have a table that has a delete rule that performs a logical delete (set a
``deleted'' column to true) whenev
On Sun, 2002-12-01 at 14:11, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > It makes sense, but I've not tested it yet.
>
> Okay, I'll hold off applying until you check it. It's not urgent,
> but I'd like to have it fixed in 7.3.1, which we'll doubtless be
> wanting to roll out in a
On Sun, 2002-12-01 at 16:35, [EMAIL PROTECTED] wrote:
> alter user nobody set search_path to [something]
>
> and then
>
> alter user nobody set search_path to default
>
> (having already done this for my own username).
>
> The database server immediately crashes
Works for me:
template1=# sele
Dustin Sallings ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
RFE - Schema list from psql
Long Description
psql should have a \d type builtin to list schemas in the current database.
Sample Code
select
ns.nspname as
Dustin Sallings ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
7.3 - timespan missing?
Long Description
I couldn't find any documentation on timespan other than saying it should be preferred
over reltime, however I use timespa
Dustin Sallings ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
7.3 crashes when trying to set variable to default
Long Description
Logged in as dustin (superuser), I did the following:
alter user nobody set search_path to [som
I've just finished the install of 7.3 release on mac
OSX 10.2.2. I notice that initdb will permit me to
init a directory for use, then when running postmaster
using the directory I get a fatal error:
FATAL: invalid value for option 'LC_TIME': 'en'
Shouldn't initdb check and not init with this
On Sun, Dec 01, 2002 at 02:06:31PM -0500, Tom Lane wrote:
> Adam Buraczewski <[EMAIL PROTECTED]> writes:
> > I already notified the author of the program and attached patches to
> > both original upgrade.pl and contrib/adddepend scripts.
> Rod, do you concur that this is a correct patch?
The patch
Rod Taylor <[EMAIL PROTECTED]> writes:
> It makes sense, but I've not tested it yet.
Okay, I'll hold off applying until you check it. It's not urgent,
but I'd like to have it fixed in 7.3.1, which we'll doubtless be
wanting to roll out in a few weeks.
regards, tom lane
-
It makes sense, but I've not tested it yet.
On Sun, 2002-12-01 at 14:06, Tom Lane wrote:
> Adam Buraczewski <[EMAIL PROTECTED]> writes:
> > Simply: the program takes column names from the wrong end of the array
> > :)
>
> > I already notified the author of the program and attached patches to
> >
Adam Buraczewski <[EMAIL PROTECTED]> writes:
> Simply: the program takes column names from the wrong end of the array
> :)
> I already notified the author of the program and attached patches to
> both original upgrade.pl and contrib/adddepend scripts.
Rod, do you concur that this is a correct pat
Philip Warner <[EMAIL PROTECTED]> writes:
>> this is caused by the cast of oprcode
> Here's a (trivial) patch.
Applied in both REL7_3 and HEAD. Thanks.
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading t
Philip Warner <[EMAIL PROTECTED]> writes:
> I guess we should get the version & refuse to connect...
We deliberately don't do that in psql. Not having working backslash
commands is not necessarily a fatal lack of functionality --- if you're
just going to issue regular SQL commands then psql will
Philip Warner <[EMAIL PROTECTED]> writes:
> Further investigation seems to indicate this is caused by the cast of
> oprcode to oid at line 1687 of pg_dump.c ("oprcode::oid"). It results in
> the output not being named 'oprcode'. I am a little surprised it's not a
> problem in the 7.3 code branch
[EMAIL PROTECTED] writes:
> Dumping from 7.2 using 7.3 gives:
> CREATE FUNCTION postgis_gist_sel (opaque, oid, opaque, integer) RETURNS double
>precision
> AS '/var/lib/pgsql7.2.1/lib/contrib/libpostgis.so.0.7', 'postgis_gist_sel'
> LANGUAGE "C";
It's fairly unlikely that the 7.2 version
I've just finished the install of 7.3 release on mac
OSX 10.2.2. I notice that initdb will permit me to
init a directory for use, then when running postmaster
using the directory I get a fatal error:
FATAL: invalid value for option 'LC_TIME': 'en'
Shouldn't initdb check and not init with this lo
Hallo,
I've used contrib/adddepend script (written in Perl) to move my
databases from PostgreSQL 7.2 to 7.3-style foreign key syntax, in
order to use new dependency information and get rid of those "create
constraint trigger" commands generated by pg_dump. The script does a
very good job indeed.
Sounds to me like your using an old version of psql with the new
database -- it will show the stale columns, but they're not really
there.
On Sun, 2002-12-01 at 07:27, Ruslan A Dautkhanov wrote:
> Hi all,
>
>
> isbs=# select version();
> version
>
At 12:16 AM 2/12/2002 +1100, Philip Warner wrote:
this is caused by the cast of oprcode
Here's a (trivial) patch.
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008
At 08:23 AM 1/12/2002 -0500, [EMAIL PROTECTED] wrote:
Maybe this is a locale thing; but ISTM it should issue a more meaningful
message or refuse to connect.
It's a schema thing; can't talk to 7.2 either. Queries sent to backend at
startup include:
BEGIN; SELECT usesuper FROM pg_catalog.pg_
Philip Warner ([EMAIL PROTECTED]) reports a bug with a severity of 4
The lower the number the more severe it is.
Short Description
psql in 7.3 can't talk to 7.1 backends
Long Description
acheron:/home/pjw/work/postgresql-7.3/src/bin/pg_dump # /var/lib/pgsql-7.3/bin/psql -p
5432 pjw
ERROR: parse
At 08:05 AM 1/12/2002 -0500, [EMAIL PROTECTED] wrote:
pg_dump: reading user-defined operators
pg_dump: column number -1 is out of range 0..4
Further investigation seems to indicate this is caused by the cast of
oprcode to oid at line 1687 of pg_dump.c ("oprcode::oid"). It results in
the output
Philip Warner ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
pg_dump in 7.3 can't dump 7.1 db
Long Description
Whenevr dumping a 7.1 db using 7.3 pg_dump, I get:
pg_dump: last built-in OID is 18539
pg_dump: saving database def
Hi all,
isbs=# select version();
version
---
PostgreSQL 7.3 on i386-unknown-freebsd4.7, compiled by GCC 2.95.4
(1 row)
isbs=# create table abba (x int4, y int4);
CREATE TABLE
isbs=# \d
Philip Warner ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
opaque->internal translation required for 7.2 dumps
Long Description
Dumping from 7.2 using 7.3 gives:
CREATE FUNCTION postgis_gist_sel (opaque, oid, opaque, integer
41 matches
Mail list logo
