Tom Lane [EMAIL PROTECTED] writes:
Tomas Berndtsson [EMAIL PROTECTED] writes:
After it tries again, it always gets error from recv() for some reason
that I don't know. I also don't understand why errno is set to ENOTTY
at this point, that makes no sense at all.
Are you sure it is set?
-Original Message-
From: Lamar Owen [mailto:[EMAIL PROTECTED]]
Sent: 05 December 2002 04:23
To: PostgreSQL-development
Subject: Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
However, I seriously question the need in the long term for
our sites to be as
I am working on getting a shrink-wrapped version of PostgreSQL for
WindowsCurrently it installs a customized version of Cygwin, PostgreSQL
7.2.3, cygipc, psqlodbc, and pgadminIII currently have the setup
done.
Cool :)
I'm now working on postmaster windows shell. It's
not finished yet but
On Wed, 4 Dec 2002 [EMAIL PROTECTED] wrote:
It is unfortunate that it is almost impossible to have a marketing group
without there being some wilful blinders involved; it's vital for there to be
some technical involvement in the marketing group to pop whatever bubbles they
grow that are
On Wed, 4 Dec 2002, Lamar Owen wrote:
However, I seriously question the need in the long term for our sites to be as
fractured as they are. Good grief! We've got advocacy.postgresql.org,
techdocs.postgresql.org, odbc.postgresql.org, gborg.postgresql.org,
developer.postgresql.org,
On Thu, 5 Dec 2002, Scott Lamb wrote:
Is this list the appropriate place to discuss the websites? or should I
take it to -advocacy? My impression here is that the two sites are
maintained separately and the people involved haven't interacted very
much. Is that accurate or no?
Expect some
This error is accompanied by a suggestion to change SEMMNI or SEMMNS.
In this case, that suggestion is not appropriate. Read below for
the scenario.
Suggestion: Can we modify the error message to include checking for a
running postmaster?
Reasoning:
During my dbinit, I found the following
Tomas Berndtsson [EMAIL PROTECTED] writes:
Indeed you were right in this. But, if I added -D_REENTRANT to the
Makefile for libpq, it started to set it. If libpq should be thread
safe, I believe it should be compiled with -D_REENTRANT.
When I did this, recv still returns error, but now sets
-Original Message-
From: Scott Lamb [mailto:[EMAIL PROTECTED]]
Sent: 05 December 2002 06:37
To: [EMAIL PROTECTED]
Subject: Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
I'm volunteering to do work here. I could at the very least
go through
the sites and make a
Tom Lane [EMAIL PROTECTED] writes:
Tomas Berndtsson [EMAIL PROTECTED] writes:
Indeed you were right in this. But, if I added -D_REENTRANT to the
Makefile for libpq, it started to set it. If libpq should be thread
safe, I believe it should be compiled with -D_REENTRANT.
When I did
Tom Lane writes:
Okay, so it seems -D_REENTRANT is the appropriate fix.
We could either add that to the template/solaris file, or just add a
note to FAQ_Solaris advising that it be added to the configure switches
if people intend to use libpq in threaded programs. Is there any
cost
We support alter table add foreign key. How about supporting
alter table drop foreign key?
- he said as he went to drop a foreign key
--
Dan Langille : http://www.langille.org/
---(end of broadcast)---
TIP 6: Have you searched our list
Lee Kindness [EMAIL PROTECTED] writes:
Tom Lane writes:
Okay, so it seems -D_REENTRANT is the appropriate fix.
We could either add that to the template/solaris file, or just add a
note to FAQ_Solaris advising that it be added to the configure switches
if people intend to use
On Thu, 5 Dec 2002, Dan Langille wrote:
We support alter table add foreign key. How about supporting
alter table drop foreign key?
- he said as he went to drop a foreign key
It seems to work for me on my 7.3b2 system with
alter table table drop constraint constraint name;
Lee Kindness [EMAIL PROTECTED] writes:
Tom Lane writes:
Okay, so it seems -D_REENTRANT is the appropriate fix.
We could either add that to the template/solaris file, or just add a
note to FAQ_Solaris advising that it be added to the configure switches
if people intend to use
Doug McNaught [EMAIL PROTECTED] writes:
Lee Kindness [EMAIL PROTECTED] writes:
Tom Lane writes:
Okay, so it seems -D_REENTRANT is the appropriate fix.
We could either add that to the template/solaris file, or just add a
note to FAQ_Solaris advising that it be added to the
On 5 Dec 2002 at 8:20, Stephan Szabo wrote:
On Thu, 5 Dec 2002, Dan Langille wrote:
We support alter table add foreign key. How about supporting
alter table drop foreign key?
- he said as he went to drop a foreign key
It seems to work for me on my 7.3b2 system with
alter table
On 5 Dec 2002 at 8:20, Stephan Szabo wrote:
On Thu, 5 Dec 2002, Dan Langille wrote:
We support alter table add foreign key. How about supporting
alter table drop foreign key?
- he said as he went to drop a foreign key
It seems to work for me on my 7.3b2 system with
alter table
On Thu, 5 Dec 2002, Dan Langille wrote:
On 5 Dec 2002 at 8:20, Stephan Szabo wrote:
On Thu, 5 Dec 2002, Dan Langille wrote:
We support alter table add foreign key. How about supporting
alter table drop foreign key?
- he said as he went to drop a foreign key
It seems to
On 5 Dec 2002 at 8:44, Stephan Szabo wrote:
On Thu, 5 Dec 2002, Dan Langille wrote:
On 5 Dec 2002 at 8:20, Stephan Szabo wrote:
On Thu, 5 Dec 2002, Dan Langille wrote:
We support alter table add foreign key. How about supporting
alter table drop foreign key?
- he
On 5 Dec 2002 at 11:47, Dan Langille wrote:
On 5 Dec 2002 at 8:44, Stephan Szabo wrote:
On Thu, 5 Dec 2002, Dan Langille wrote:
On 5 Dec 2002 at 8:20, Stephan Szabo wrote:
On Thu, 5 Dec 2002, Dan Langille wrote:
We support alter table add foreign key. How about
On Thursday 05 December 2002 09:37, Marc G. Fournier wrote:
On Wed, 4 Dec 2002, Lamar Owen wrote:
However, I seriously question the need in the long term for our sites to
be as fractured as they are. Good grief! We've got
note that altho they are seperate URLs, the end result is going to
On Thu, 5 Dec 2002, Dan Langille wrote:
Found the solution:
drop trigger RI_ConstraintTrigger_4278488 on watch_list_staging;
Actually there are three triggers for the constraint. You may have
dangling triggers on the other table of the constraint. It's one on the
table the constraint's
On 5 Dec 2002 at 9:02, Stephan Szabo wrote:
On Thu, 5 Dec 2002, Dan Langille wrote:
Found the solution:
drop trigger RI_ConstraintTrigger_4278488 on watch_list_staging;
Actually there are three triggers for the constraint. You may have
dangling triggers on the other table of the
On Thu, 5 Dec 2002, Dan Langille wrote:
On 5 Dec 2002 at 9:02, Stephan Szabo wrote:
On Thu, 5 Dec 2002, Dan Langille wrote:
Found the solution:
drop trigger RI_ConstraintTrigger_4278488 on watch_list_staging;
Actually there are three triggers for the constraint. You may have
On 5 Dec 2002 at 9:31, Stephan Szabo wrote:
When we talk about ALTER TABLE ADD FOREIGN KEY we're being imprecise, so
I think that might be why we're talking past each other here.
Technically the syntax in question is:
ALTER TABLE table ADD table constraint definition
where CONSTRAINT name
Hey this is a cool project. I have been thinking doing the exact ame thing,
the console Window of 2K/XP just kills the daemon, yuck.
What can I do to help?
Igor Georgiev wrote:
I am working on getting a shrink-wrapped version of PostgreSQL
for Windows
Currently it
On Thu, 5 Dec 2002, Dan Langille wrote:
On 5 Dec 2002 at 9:31, Stephan Szabo wrote:
When we talk about ALTER TABLE ADD FOREIGN KEY we're being imprecise, so
I think that might be why we're talking past each other here.
Technically the syntax in question is:
ALTER TABLE table ADD
On 5 Dec 2002 at 9:51, Stephan Szabo wrote:
On Thu, 5 Dec 2002, Dan Langille wrote:
On 5 Dec 2002 at 9:31, Stephan Szabo wrote:
When we talk about ALTER TABLE ADD FOREIGN KEY we're being imprecise, so
I think that might be why we're talking past each other here.
Technically the
I am poking around at upgrading PostGIS to work with version 7.3. So
far, the changes seem relatively minor. There is one odd quirk though.
Having gotten the PostGIS types and index bindings loaded, and having
loaded a table full of spatial data, trying to do
\d thetable
returns
ERROR:
Lee Kindness [EMAIL PROTECTED] writes:
Tom Lane writes:
Okay, so it seems -D_REENTRANT is the appropriate fix.
However, _REENTRANT is not a Solarisism... On all (recent) UNIX
systems it toggles on correct handling for thread specific instances
of historically global variables (eg errno). It
Thanks. I guess I should rename my thread to 7.4 - TODO : allow
constraint names when using the ALTER TABLE table ADD FOREIGN KEY
syntax.
You can do that now.
ALTER TABLE table ADD CONSTRAINT const FOREIGN KEY
--
Rod Taylor [EMAIL PROTECTED]
PGP Key: http://www.rbt.ca/rbtpub.asc
On further investigation, the problem is related to using a 7.2 psql
against a 7.3 backend. The \d from the 7.2 psql is not compatible with
the 7.3 backend in the case of tables with non-standard types apparently.
P.
Paul Ramsey wrote:
I am poking around at upgrading PostGIS to work with
Dan Langille wrote: On 5 Dec 2002 at 11:47, Dan Langille wrote:
Primary key: watch_list_staging_pkey
Check constraints: watch_list_stag_from_watch_list
((from_watch_list = 't'::bool) OR (from_watch_list = 'f'::bool))
watch_list_stagin_from_pkg_info ((from_pkg_info
=
Don't do it! It's a wrong patch. Dan will prepare correct patch (with other
changes).
Bruce Momjian wrote:
Dan, is this ready to be applied to CVS?
---
Dan Langille wrote:
I have been looking at contrib/ltree in the
Thanks for asking. I have been diverted to other tasks and won't be
able to get back to this for a short while. The basics work (i.e.
population and simple compares) but I know for sure that certain
functions will not work now that we allow what were previously
operators to be part of the
Bruce Momjian writes:
Tom Lane wrote:
Lee Kindness [EMAIL PROTECTED] writes:
Perhaps the .so name should have been updated for PostgreSQL 7.3?
It should have been. If it wasn't, that was a serious oversight.
Not sure if we should change it in 7.3.1 or not, though; it may be
On Thu, 5 Dec 2002, Philip Warner wrote:
At 05:48 PM 4/12/2002 -0800, Christopher Kings-Lynne wrote:
Lack of marketing is one of Postgres's major problems.
What are the consequences of the problem?
Well, I'd have to say the major one is a difficult in increasing our user
base, as ppl like
On Thu, 2002-12-05 at 03:28, Dave Page wrote:
www is a closed group consisting of a few of us who actually do the work
on the sites.
This is one of the primary reasons the sites are so fractured. We have 4
different mailing lists for website development (and I'm not counting
advocacy as one of
Marc G. Fournier wrote:
On Wed, 4 Dec 2002 [EMAIL PROTECTED] wrote:
It is unfortunate that it is almost impossible to have a marketing group
without there being some wilful blinders involved; it's vital for there to be
some technical involvement in the marketing group to pop whatever
On 5 Dec 2002 at 14:17, Fernando Nasser wrote:
Dan Langille wrote: On 5 Dec 2002 at 11:47, Dan Langille wrote:
drop trigger RI_ConstraintTrigger_4278488 on watch_list_staging;
You should now go to the table this RI constraint was referring to and delete
the two triggers in there as
Thanks. I guess I should rename my thread to 7.4 - TODO : allow
constraint names when using the ALTER TABLE table ADD FOREIGN KEY
syntax.
You can do that now.
ALTER TABLE table ADD CONSTRAINT const FOREIGN KEY
That I know. That syntax is radically different from that
On 5 Dec 2002 at 11:52, Christopher Kings-Lynne wrote:
Thanks. I guess I should rename my thread to 7.4 - TODO : allow
constraint names when using the ALTER TABLE table ADD FOREIGN KEY
syntax.
You can do that now.
ALTER TABLE table ADD CONSTRAINT const FOREIGN KEY
Isn't it identical? The CONSTRAINT const is SQL standard optional
clause
for all commands that add constraints.
Except that one is ADD CONSTRAINT, the other is an ADD FOREIGN KEY.
They are similar in nature but different overall.
I think you're getting a little confused here, Dan.
On Thu, 2002-12-05 at 14:52, Christopher Kings-Lynne wrote:
Thanks. I guess I should rename my thread to 7.4 - TODO : allow
constraint names when using the ALTER TABLE table ADD FOREIGN KEY
syntax.
You can do that now.
ALTER TABLE table ADD CONSTRAINT const FOREIGN KEY
Paul Ramsey [EMAIL PROTECTED] writes:
\d thetable
returns
ERROR: Relation pg_relcheck does not exist
I think you are using a 7.2 psql with the 7.3 server. There will be
quite a few problems with backslash commands in that combination
(or the reverse), because of the extensive catalog
On 5 Dec 2002 at 12:09, Christopher Kings-Lynne wrote:
Isn't it identical? The CONSTRAINT const is SQL standard optional
clause
for all commands that add constraints.
Except that one is ADD CONSTRAINT, the other is an ADD FOREIGN KEY.
They are similar in nature but different
Dan Langille [EMAIL PROTECTED] writes:
You can do that now.
ALTER TABLE table ADD CONSTRAINT const FOREIGN KEY
That I know. That syntax is radically different from that proposed.
So you're proposing we replace a SQL-spec-compliant syntax with one
that is not? Why?
On 5 Dec 2002 at 15:36, Tom Lane wrote:
Dan Langille [EMAIL PROTECTED] writes:
You can do that now.
ALTER TABLE table ADD CONSTRAINT const FOREIGN KEY
That I know. That syntax is radically different from that proposed.
So you're proposing we replace a SQL-spec-compliant syntax
Hi guys,
Messing about with ADD COLUMN...
I'm not certain how to re-evaluate the default expression for each row? How
do I do this? I have access to raw_default and cooked_default it seems.
Thanks,
Chris
---(end of broadcast)---
TIP 4: Don't
Igor Georgiev wrote:
snip
I also be GLAD to read about plans for native windows port in 7.4.
If anyone is interested i can post source code, or maybe this firrst
steps can go to gborg as a separate project
i'm not sure yet.
Hi Igor,
This would be a really good thing to get into GBorg as a
Justin Clift wrote:
Igor Georgiev wrote:
snip
I also be GLAD to read about plans for native windows port in 7.4.
If anyone is interested i can post source code, or maybe this firrst
steps can go to gborg as a separate project
i'm not sure yet.
Hi Igor,
This would be a really good thing
Hi
appended below is a simple database schema (which may not
be a candidate for the next Nobel Prize for SQL Database
Design, but represents enough of a production
database to demonstrate the following problem).
And that is:
under 7.3 this statement:
SELECT foo_id, thingy_name, bar_name
Justin Clift wrote:
Hi Igor,
This would be a really good thing to get into GBorg as a project, so
people could work on this through CVS.
Would you like to register it as a project?
Mark, do you feel it would be better to put your installer plus this
together into one project on GBorg too?
It works very similarly to the way that ALTER TABLE ... ADD CHECK ..
works, with the tuple update added in.
Anyway, it's something like the below:
- Lock relation
- Pull out tuple
- Evaluate cooked default expression using EvalExpr
- heap_modifytuple (shove datum that EvalExpr returns into
mlw wrote:
snip
Once we do that, the we have the hook for more reliable and powerful
systems.
Yep, I pretty much agree.
:-)
Regards and best wishes,
Justin Clift
--
My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Really it boils down to one point: there's really no reason to assume a user
should be able to execute any new query he feels like. Creating a new query
should be privileged operation just like creating a new table or
--On Thursday, December 05, 2002 14:02:04 -0500 Tom Lane
[EMAIL PROTECTED] wrote:
Lee Kindness [EMAIL PROTECTED] writes:
Tom Lane writes:
Okay, so it seems -D_REENTRANT is the appropriate fix.
However, _REENTRANT is not a Solarisism... On all (recent) UNIX
systems it toggles on correct
Tom Lane wrote:
Lee Kindness [EMAIL PROTECTED] writes:
Tom Lane writes:
Okay, so it seems -D_REENTRANT is the appropriate fix.
However, _REENTRANT is not a Solarisism... On all (recent) UNIX
systems it toggles on correct handling for thread specific instances
of historically global
At 12:12 AM 5/12/2002 -0500, Robert Treat wrote:
What are the consequences of the problem?
One consequence that probably hits home for everyone here is it makes it
extremely hard to make a living working with postgresql.
...
You can't win marketshare on technology alone
I am happy with
On Thu, 05 Dec 2002 21:26:13 -0500, Philip Warner wrote:
At 12:12 AM 5/12/2002 -0500, Robert Treat wrote:
I am happy with increasing market share so long a development is not
distorted or current users inconvenienced. We have seen the latter with
the misplaced announcements.
It seems to me
I just sync'd up with cvs and tried to make clean then configure, and I'm
getting this:
config.status: linking ./src/backend/libpq/v6util.c to
src/interfaces/libpq/v6util.c
config.status: error: ./src/backend/libpq/v6util.c: file not found
Is this a missing file from the ipv6 stuff that just
Justin:
Are you involved with gborg?
I have been thinking about Igor's console and my installer. I think
there is a good enough need to host a project that contains HOWTOs,
scripts, and tools to make PostgreSQL easy for Windows deployment.
I am working on a HOWTO, a set of Windows batch
Hi Mark,
mlw wrote:
Justin:
Are you involved with gborg?
Nope, that's Chris Ryan's area. :)
I have been thinking about Igor's console and my installer. I think
there is a good enough need to host a project that contains HOWTOs,
scripts, and tools to make PostgreSQL easy for Windows
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Marc G. Fournier writes:
It isn't, but those working on -advocacy were asked to help come up with a
stronger release *announcement* then we've had in the past ...
Consider that a failed experiment. PostgreSQL is driven by the
Lee Kindness wrote:
Bruce Momjian writes:
Tom Lane wrote:
Lee Kindness [EMAIL PROTECTED] writes:
Perhaps the .so name should have been updated for PostgreSQL 7.3?
It should have been. If it wasn't, that was a serious oversight.
Not sure if we should change it in 7.3.1 or
Bruce Momjian wrote:
I will update for 7.4 now. Too late for 7.3 clearly.
Bruce, why is it too late?
Most (all) will upgrade to 7.3.1 anyway, so it is a chance to get things right.
--
Fernando Nasser
Red Hat - Toronto E-Mail: [EMAIL PROTECTED]
2323 Yonge Street,
Fernando Nasser wrote:
Bruce Momjian wrote:
I will update for 7.4 now. Too late for 7.3 clearly.
Bruce, why is it too late?
Most (all) will upgrade to 7.3.1 anyway, so it is a chance to get things right.
Oh. yes. Is it safe to do that?
--
Bruce Momjian
Bruce Momjian [EMAIL PROTECTED] writes:
Fernando Nasser wrote:
Bruce Momjian wrote:
Bruce, why is it too late?
Most (all) will upgrade to 7.3.1 anyway, so it is a chance to get things right.
Oh. yes. Is it safe to do that?
The RPM packagers should probably have a say in this, but I'm
On Thu, 5 Dec 2002, Bruce Momjian wrote:
It looks like the problem was introduced when the SET autocommit
and SET search_path commands were added to the beginning of the script.
The attatched patch should fix the problem. It probably should be applied
against the 7.3 and 7.4 branches.
Bruce Momjian wrote:
I am not going to apply this patch because I think it will mess up the
handling of other locales.
As far as I figured from the source code this function only deals with
cleaning up
locale names and nothing else. Since all the locale names are in plain
ASCII I think
it
Thanks. Applied to 7.3 and CVS HEAD. It was me who added those
commands to set the envirnment, and I didn't realize it was the first
use of those variables, hence the need for 'my'.
Thanks. Fix will be in 7.3.1.
---
Jeroen T. Vermeulen wrote:
On Thu, Dec 05, 2002 at 03:27:23PM -0500, Tom Lane wrote:
It is not real clear to me whether we need a major version bump, rather
than a minor one. We *do* need to signal binary incompatibility. Who
can clarify the rules here?
One thing I wonder about:
Tom Lane writes:
It is not real clear to me whether we need a major version bump, rather
than a minor one. We *do* need to signal binary incompatibility. Who
can clarify the rules here?
Strictly speaking, it's platform-dependent, but our shared library code
plays a bit of abuse with it.
Bruce Momjian writes:
I am not going to apply this patch because I think it will mess up the
handling of other locales.
This patch looks OK to me. Normally, character set names should use
identifier case-folding rules anyway, so seems to be a step in the right
direction. Much better than
OK, Peter, that helps. Thanks. I will apply it.
---
Peter Eisentraut wrote:
Bruce Momjian writes:
I am not going to apply this patch because I think it will mess up the
handling of other locales.
This patch
OK, patch applied. Peter, should this appear in 7.3.1 too?
---
Peter Eisentraut wrote:
Bruce Momjian writes:
I am not going to apply this patch because I think it will mess up the
handling of other locales.
This
Folks,
We have a marketing group: PGSQL-ADVOCACY. Our problem is that we
don't have enough volunteers.
For example, last week Robert and Justin had job crises, and I left for
the mountains for Thanksgiving. As a result Marc had to pitch in at
the last minute to try to get some kind of release
Fixing now. This just isn't my night --- another patch with a missing
file.
---
Joe Conway wrote:
I just sync'd up with cvs and tried to make clean then configure, and I'm
getting this:
config.status: linking
Bruce Momjian wrote:
Fixing now. This just isn't my night --- another patch with a missing
file.
OK - I can run configure and make now, but I'm getting these warnings:
In file included from ../../../../src/include/libpq/libpq.h:22,
from printtup.c:20:
Yep, I am about to yank out the whole patch. I am seeing on postmaster
startup:
LOG: FATAL: StreamServerPort: getaddrinfo2() failed: hostname
nor servname provided, or not known
What is strange is that initdb worked. I will just throw it back to the
author.
Done.
Bruce Momjian wrote:
Yep, I am about to yank out the whole patch. I am seeing on postmaster
startup:
LOG: FATAL: StreamServerPort: getaddrinfo2() failed: hostname
nor servname provided, or not known
What is strange is that initdb worked. I will just throw it back to the
author.
Done.
BJoe Conway wrote:
Bruce Momjian wrote:
Yep, I am about to yank out the whole patch. I am seeing on postmaster
startup:
LOG: FATAL: StreamServerPort: getaddrinfo2() failed: hostname
nor servname provided, or not known
What is strange is that initdb worked. I will
Bruce Momjian wrote:
Sorry. Run autoconf.
OK -- works now. I've never needed to do that before.
Thanks!
Joe
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL
The INETv6 patch was rejected because of this report, and an error on
postmaster startup from BSD/OS:
LOG: FATAL: StreamServerPort: getaddrinfo2() failed: hostname nor
servname provided, or not known
Please submit a new patch that addresses these issues. I can work with
you to
Patch applied to HEAD and 7.3. Thanks.
---
Teodor Sigaev wrote:
Thank you very much, you catch it :). This bug had a long life, because it
exists if and only if locale of postmaster
was a different from C (or
I don't think you can drop/recreate the sequence because the dependency
code knows other tables depend on it.
---
Rajesh Kumar Mallah. wrote:
Doesn't dropping and recreating the sequence suit the bill ?
whats' the
Due to a late-night typo, the 7.3-1 RPMset released last night would start the
postmaster for the first time, but not subsequent times. I have corrected
the problem and uploaded a 7.3-2 RPMset. If you do not want to download the
whole set again to fix a single-character bug, edit the file
88 matches
Mail list logo
