[HACKERS] Recursive unions

[Christopher Kings-Lynne]

Hi guys,

What was the result of the recursive unions thread?  I remember Tom maybe
saying that the Redhat guys like the DB2 (SQL99) syntax the best, however
was it said that that was going to be done by Redhat for 7.4?

Chris


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Strange Prepare bug

[Tom Lane]

Rod Taylor <[EMAIL PROTECTED]> writes:
> PREPARE "pg_psql_dd2"(text,text) AS=20
> SELECT true
> FROM (
>   SELECT true
>   FROM pg_catalog.pg_proc p,
>pg_catalog.pg_name_pattern( $2 ) AS (schpat text, propat text)
>   WHERE p.prorettype <> 'pg_catalog.cstring'::pg_catalog.regtype
> ) AS tt,
>   (SELECT $1 AS cmd) AS cmd;

> ERROR:  Parameter '$1' is out of range

I get

ERROR:  Function pg_catalog.pg_name_pattern(text) does not exist

It could be the error is inside your custom function?

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Specifying Rowtypes

[Stephan Szabo]

On Wed, 29 Jan 2003, Curt Sampson wrote:

>
> So currently the only way to specify a row type is by using a table,
> right? E.g.:
>
> CREATE TABLE t2_retval (
>   value1 int NOT NULL DEFAULT -1,
>   value2 int NOT NULL,
>   value3 int
> );
>
> Are there plans to add another way of declaring this sort of thing so
> that I don't have to add a new table to my schema for every function
> that returns a rowtype?

You can also return records at which point you have to give a definition
at select time.

create function aa1() returns record as 'select 1,2;' language 'sql';
select * from aa1() as aa1(a int, b int);

Also, for defined types like that, you probably want to use
CREATE TYPE ... AS rather than CREATE TABLE.

> Second, it seems that there's still a problem with NULLs here:
>
> CREATE FUNCTION t2()
>   RETURNS t2_retval
> AS '
> DECLARE
>   retval t2_retval%ROWTYPE;
> BEGIN
>   SELECT INTO retval null, null, null;
>   RETURN retval;
> END
> ' LANGUAGE 'plpgsql';
>
> This is returning a row that (to my mind) doesn't match the type of the
> table above, because it's returning null for non-nullable columns:

I believe only the column names and types are considered for purposes of
this.  Check constraints and the like defined on the column aren't applied
either.  I can see arguments for both ways since things like foreign keys
or the not yet supported check constraints with subselects would seem to
have not terribly meaningful results.

Although if you make the column on a domain and the domain has a
constraint it does seem to be applied.


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] poor performance of subquery in psql

[Tom Lane]

"John Liu" <[EMAIL PROTECTED]> writes:
> why psql subquery is not smarter enough to use
> indexes if obviously?

IN is smarter as of CVS tip.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

[HACKERS] FW: [GENERAL] problems with dropped columns

[Christopher Kings-Lynne]

This came to -general, it seems like a serious problem...

Chris


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]]On Behalf Of Damjan Pipan
> Sent: Tuesday, 28 January 2003 9:36 PM
> To: [EMAIL PROTECTED]
> Subject: [GENERAL] problems with dropped columns 
> 
> 
> Hi!
> 
> I have following problem:
> I have created a table with some fields, then I dropped last 
> field (integer)
> and added
> one extra field (integer). Then I have created a function which returns
> record of table
> type. I have selected a record from table and returned it, but 
> the values in
> last
> field are wrong (missing). It looks like that it takes the dropped field
> instead of the last field.
> 
> Damjan
> 
> CREATE OR REPLACE FUNCTION damjan_test111(integer) RETURNS 
> public.fk_test AS
> '
> DECLARE
> rec fk_test%ROWTYPE;
> siteid ALIAS FOR $1;
> BEGIN
> FOR rec IN SELECT * FROM public.fk_test WHERE
> i = siteid LOOP
> RETURN rec;
> END LOOP;
> END;
> ' LANGUAGE 'plpgsql';
> 
> 
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Specifying Rowtypes

[Christopher Kings-Lynne]

No, in 7.3 you can create anonymous composite types using the CREATE TYPE
command.

Chris

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Curt Sampson
> Sent: Wednesday, 29 January 2003 1:45 PM
> To: PostgreSQL Development
> Subject: [HACKERS] Specifying Rowtypes
>
>
>
> So currently the only way to specify a row type is by using a table,
> right? E.g.:
>
> CREATE TABLE t2_retval (
>   value1 int NOT NULL DEFAULT -1,
>   value2 int NOT NULL,
>   value3 int
> );
>
> Are there plans to add another way of declaring this sort of thing so
> that I don't have to add a new table to my schema for every function
> that returns a rowtype?
>
> Second, it seems that there's still a problem with NULLs here:
>
> CREATE FUNCTION t2()
>   RETURNS t2_retval
> AS '
> DECLARE
>   retval t2_retval%ROWTYPE;
> BEGIN
>   SELECT INTO retval null, null, null;
>   RETURN retval;
> END
> ' LANGUAGE 'plpgsql';
>
> This is returning a row that (to my mind) doesn't match the type of the
> table above, because it's returning null for non-nullable columns:
>
> cjs=> select coalesce(value1, -999), coalesce(value2, -999),
> cjs-> coalesce(value3, -999) from t2();
>  case | case | case
> --+--+--
>  -999 | -999 | -999
> (1 row)
>
> (You get the same result if you delete the SELECT INTO line above.)
>
> Am I misunderstanding something here, or is this a bug?
>
> cjs
> --
> Curt Sampson  <[EMAIL PROTECTED]>   +81 90 7737 2974   http://www.netbsd.org
> Don't you know, in this new Dark Age, we're all light.  --XTC
>
> ---(end of broadcast)---
> TIP 4: Don't 'kill -9' the postmaster
>


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?

[Tom Lane]

"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> On Sat, Jan 25, 2003 at 09:55:25PM -0500, Bruce Momjian wrote:
>> If we can get them all, it is a big win.  If we can't, I don't think it
>> is a win.

> In the context of backporting, this is true, but in general, if you
> don't worry about putting locks on any of the doors, because there are
> other ones open, you _never_ get them all.

We certainly are trying to get them all going forward.  The issue here
is what is reasonable to back-patch into 7.2 (or 7.3), given the ground
rules that we can no longer force an initdb for users of those releases.
Those ground rules mean that some bugs are unfixable in those releases.

How hard should we try to back-patch fixes for fixable bugs of severity
comparable to the unfixable bugs?  Before you answer, consider that any
time spent doing so takes away from current/future development work;
"fix it without regard to cost" is not really a defensible stance.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [mail] Re: [HACKERS] Windows Build System

[Tom Lane]

"Curtis Faith" <[EMAIL PROTECTED]> writes:
> If a developer can simply download the source, click on the Visual C++
> project in the win32 directory and then build PostgreSQL, and they can
> see that Windows is not the "poor stepchild" because the VC project is
> well laid out, they will be more likely to use it for Windows projects
> than MySQL which requires the CygWin tools (this means "really a Unix
> product" to Windows developers).


In all honesty, I do not *want* Windows people to think that they're not
running on the "poor stepchild" platform.If we go down that path,
they'll start trying to run production databases on Windows, and then
we'll get blamed for the instability of the platform, not to mention
the likelihood that it ignores Unix semantics for fsync() and suchlike
critical primitives.

I have no objection to there being a Windows port that people can use
to do SQL-client development on their laptops.  But let us please not
confuse this with an industrial-strength solution; nor give any level
of support that might lead others to make such confusion.

The MySQL guys made the right choice here: they don't want to buy into
making Windows a grade-A platform, either.


regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] [GENERAL] tsearch comments

[Oleg Bartunov]

On 28 Jan 2003, [EMAIL PROTECTED] wrote:

> Hi,
>
> I guess what we're looking for is something on the order (as much as I
> hate using it as a reference) of MySQL's full text search which does
> offer some ranking.
>
> Just putting ranking alone in tsearch would be a huge benefit. Users can
> then decide in their own language how to display results, especially
> since those results may not necessarily require titles or description
> fragments.
>
> For example, we have several huge tables that have the following
> columns:
>
> > id
> > tbltype
> > title
> > description
>
> Basically, our customer will lookup words that are contained in title
> and description, so we make an additional table like:
>
> > id
> > tblid (id of the source table)
> > tblsource (which table)
> > content (txtidx)
>
> Then we can use tsearch to search the second table (we do now), and once
> we retrieve the id's that we want, we can display results from one or
> more source tables. Just putting in ranking in tsearch would solve all
> these problems.

Hmm, people used to concatenation to get the same result. Do you really
need that table ? Your problem doesn't relate to ranking of results.

We could add some ranking support based on local (per-document) statistics.
Keeping global statistics, for example, TFxIDF, would complicate tsearch
and maintaining of indices. Proximity ranking as in OpenFTS require
more options in tsearch configuration. Let us think about ranking later
after we implement friendly interface.

>
> - Ericson Smith
> http://www.did-it.com
> http://www.weightlossfriends.com
>
>
> On Tue, 2003-01-28 at 14:00, Oleg Bartunov wrote:
> > On Tue, 28 Jan 2003, Uros Gruber wrote:
> >
> > > Hi!
> > >
> > > I think that this would be nice. OpenFTS is great, but i would
> > > be great if this would be implement in real pg functions.
> > >
> > > I think that indexim would be great if pg make it by itself.
> > >
> > > Also it could be great if we could define order of weight of
> > > columns.
> >
> > Could you elaborate this ?
> >
> > >
> > > bye Uros
> > >
> > > I
> > > On 28.01.2003 at 11:53:26, Oleg Bartunov <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > On Tue, 28 Jan 2003 [EMAIL PROTECTED] wrote:
> > > >
> > > > > HI
> > > > >
> > > > > will we see sort by relevance at tsearch alpha version? :)
> > > > >
> > > >
> > > > not sure. We concentrate our efforts, well, Teodor is working
> > > > on
> > > > better configurability of tsearch like OpenFTS does.
> > > >
> > > > It\\\'s not difficult to add rather naive relevance based on
> > > > position
> > > > of lexem in document, for example. The question is do you
> > > like
> > > > such
> > > > kind of relevancy ? Real ranking support (as in OpenFTS)
> > > > require
> > > > separate tables to maintain coordinate information.
> > > > We want to keep tsearch as simple as it\\\'s and now we just
> > > add
> > > > better and friendly configurability. Do we need complicate
> > > > tsearch ?
> > > > We already have OpenFTS which has most features people
> > > > requested.
> > > >
> > >
> > >
> > > ---(end of broadcast)---
> > > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
> > >
> >
> > Regards,
> > Oleg
> > _
> > Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
> > Sternberg Astronomical Institute, Moscow University (Russia)
> > Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
> > phone: +007(095)939-16-83, +007(095)939-23-83
> >
> >
> > ---(end of broadcast)---
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to [EMAIL PROTECTED] so that your
> > message can get through to the mailing list cleanly
>
>
>
> ---(end of broadcast)---
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
>

Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Specifying Rowtypes

[Tom Lane]

Curt Sampson <[EMAIL PROTECTED]> writes:
> So currently the only way to specify a row type is by using a table,

No, as of 7.3 there's CREATE TYPE foo AS (column list).  But ...

> This is returning a row that (to my mind) doesn't match the type of the
> table above, because it's returning null for non-nullable columns:

The current behavior of a rowtype doesn't include any constraint checks.
Feel free to design a solution ...

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Specifying Rowtypes

[Curt Sampson]

On Tue, 28 Jan 2003, Stephan Szabo wrote:

> You can also return records at which point you have to give a definition
> at select time.
>
> create function aa1() returns record as 'select 1,2;' language 'sql';
> select * from aa1() as aa1(a int, b int);

Yeah, I tried that approach too, but it got ugly quickly. Changing that
line in all my unit tests every time I changed the signature of the return
value was a fair amount of extra effort.

> Also, for defined types like that, you probably want to use
> CREATE TYPE ... AS rather than CREATE TABLE.

That's much better! Thanks!

> I believe only the column names and types are considered for purposes of
> this.  Check constraints and the like defined on the column aren't applied
> either.  I can see arguments for both ways since things like foreign keys
> or the not yet supported check constraints with subselects would seem to
> have not terribly meaningful results.

Well, it might make sense to declare that you can't return anything that
couldn't, in the current transaction, be inserted into that table.

But easier, perhaps, would just be to provide the ability to add limited
constraints to CREATE TYPE, and only honour the constranints that can be
applied in a CREATE TYPE statement.

> Although if you make the column on a domain and the domain has a
> constraint it does seem to be applied.

Hmmm. Interesting. This would be basically what I described above, then,
wouldn't it, except it doesn't work for me (with types or tables):

CREATE DOMAIN nonnull_int AS
int
DEFAULT 0
CONSTRAINT nonnull_int_not_null NOT NULL;

CREATE TYPE t2_retval AS (
value1 nonnull_int,
value2 nonnull_int,
value3 nonnull_int
);

CREATE FUNCTION t2()
RETURNS SETOF t2_retval
AS '
DECLARE
retval t2_retval%ROWTYPE;
BEGIN
SELECT INTO retval 1;
RETURN NEXT retval;
SELECT INTO retval 1, 2, 3;
RETURN NEXT retval;
SELECT INTO retval null, null, null;
RETURN NEXT retval;
RETURN;
END
' LANGUAGE 'plpgsql';

SELECT * FROM t2();

...produces rows with nulls in them.

cjs
-- 
Curt Sampson  <[EMAIL PROTECTED]>   +81 90 7737 2974   http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light.  --XTC

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

[HACKERS] signal handling

[Luis Alberto Amigo Navarro]

hi all:
is there any unused signal on 
postgres?
TIA and regards

Re: [HACKERS] Strange Prepare bug

[Rod Taylor]

> I get
> 
> ERROR:  Function pg_catalog.pg_name_pattern(text) does not exist
> 
> It could be the error is inside your custom function?

I forgot that is a new function :)


Try this one:

PREPARE "pg_psql_dd2"(text,text) AS 
SELECT true
FROM (
  SELECT true
  FROM pg_catalog.pg_proc p,
   (SELECT substr($2, 1, 3) as schpat, substr($2, 3, 5) as propat)
as t
  WHERE p.prorettype <> 'pg_catalog.cstring'::pg_catalog.regtype
) AS tt,
  (SELECT $1 AS cmd) AS cmd

-- 
Rod Taylor <[EMAIL PROTECTED]>

PGP Key: http://www.rbt.ca/rbtpub.asc



signature.asc
Description: This is a digitally signed message part

[HACKERS] client_encoding directive is ignored in postgresql.conf

[Tatsuo Ishii]

There is a nasty bug with the client_encoding directive in
postgresql.conf. It is simply ignored. This bug exists in both 7.3 or
later and in current. Interesting thing is "show client_encoding"
command shows expected encoding but this only shows the GUC internal
variable and the actual internal encoding state does not reflect
postgresql.conf. The cause of the bug is as follows:

1) postgresql.conf is read by GUC while postmaster starting up.
2) assign_client_encoding() is called to reflect client_encoding
   directive in postgresq.conf
3) Since database access is not available during GUC processing, it
   just set GUC variable and leave the real client encoding state as
   it is.

Possible solution would be setting a flag during 2) and doing actual
client encoding processing after the database access becomes
possible. Included patches (against 7.3 stable tree) implement
this. New function InitializeClientEncoding() does client encoding
things and is called between call to InitializeSearchPath() and
on_shmem_exit() in InitPostgres().

Comments?

P.S.Related bug exists in
fe-connect.c:PostgresPollingStatusType(). In this function to set the
client side encoding, getdatabaseencoding() is called. This is simply
wrong since it does not return the client encoding specified by
postgressql.conf's client_encoding directive. Instead
pg_client_encoding() should be called. (fix to this is included in the
patches)
--
Tatsuo Ishii

---
Index: backend/utils/init/postinit.c
===
RCS file: /cvsroot/pgsql-server/src/backend/utils/init/postinit.c,v
retrieving revision 1.117.2.1
diff -c -r1.117.2.1 postinit.c
*** backend/utils/init/postinit.c   21 Nov 2002 06:36:27 -  1.117.2.1
--- backend/utils/init/postinit.c   29 Jan 2003 13:13:04 -
***
*** 397,402 
--- 397,405 
/* set default namespace search path */
InitializeSearchPath();
  
+   /* initialize client encoding */
+   InitializeClientEncoding();
+ 
/*
 * Set up process-exit callback to do pre-shutdown cleanup.  This
 * should be last because we want shmem_exit to call this routine
Index: backend/utils/mb/mbutils.c
===
RCS file: /cvsroot/pgsql-server/src/backend/utils/mb/mbutils.c,v
retrieving revision 1.36.2.1
diff -c -r1.36.2.1 mbutils.c
*** backend/utils/mb/mbutils.c  26 Nov 2002 02:37:13 -  1.36.2.1
--- backend/utils/mb/mbutils.c  29 Jan 2003 13:13:05 -
***
*** 37,42 
--- 37,44 
int len, bool 
is_client_to_server);
  static int cliplen(const unsigned char *str, int len, int limit);
  
+ /* Flag to we need to initialize client encoding info */
+ static bool need_to_init_client_encoding = -1;
  
  /*
   * Set the client encoding and save fmgrinfo for the converion
***
*** 58,63 
--- 60,72 
if (!PG_VALID_FE_ENCODING(encoding))
return (-1);
  
+   /* If we cannot actualy set client encoding info, remeber it
+* so that we could set it using InitializeClientEncoding()
+* in InitPostgres()
+*/
+   if (current_server_encoding != encoding && !IsTransactionState())
+   need_to_init_client_encoding = encoding;
+ 
if (current_server_encoding == encoding ||
(current_server_encoding == PG_SQL_ASCII || encoding == PG_SQL_ASCII))
{
***
*** 113,118 
--- 122,140 
ToClientConvProc = to_client;
}
return 0;
+ }
+ 
+ /* Initialize client encoding if necessary.
+  * called from InitPostgres() once during backend starting up.
+  */
+ void
+ InitializeClientEncoding()
+ {
+   if (need_to_init_client_encoding > 0)
+   {
+   SetClientEncoding(need_to_init_client_encoding, 1);
+   need_to_init_client_encoding = -1;
+   }
  }
  
  /*
Index: include/mb/pg_wchar.h
===
RCS file: /cvsroot/pgsql-server/src/include/mb/pg_wchar.h,v
retrieving revision 1.44
diff -c -r1.44 pg_wchar.h
*** include/mb/pg_wchar.h   4 Sep 2002 20:31:42 -   1.44
--- include/mb/pg_wchar.h   29 Jan 2003 13:13:25 -
***
*** 295,300 
--- 295,301 
  
  extern void SetDefaultClientEncoding(void);
  extern intSetClientEncoding(int encoding, bool doit);
+ extern void   InitializeClientEncoding(void);
  extern intpg_get_client_encoding(void);
  extern const char *pg_get_client_encoding_name(void);
  
Index: interfaces/libpq/fe-connect.c
===
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.213.2.1
diff -c -r1.213.2.1 fe-connect.c
*** inter

Re: [HACKERS] Request for qualified column names

[Reggie Burnett]

I'm certainly not trying to be difficult, I just don't know a lot about
the internals of PostgreSQL.  I'm developing some interfaces to various
databases and certainly wanted to include PostgreSQL.

>From my less-than-qualified viewpoint, I would have thought including
the base table name and bit pattern indicating certain features
(nullability, primary index, etc) for each column in the RowDescriptor
message would have been the best.  Since my driver will need to support
current and previous versions of PostgreSQL, my plan is to write some
code to parse a SQL statement and extract the table names. (ugh!)

One approach might be to add the tables's oid to the RowDescriptor
message.  Would not be perfect since I still would have many roundtrips
to the database to get metadata, but since I don't need metadata in
every case I can leave that step out until someone requests it.

Reggie

> -Original Message-
> From: Neil Conway [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 28, 2003 11:47 PM
> To: Reggie Burnett
> Cc: 'Tom Lane'; 'Dave Cramer'; 'PostgreSQL Hackers Mailing List'
> Subject: Re: [HACKERS] Request for qualified column names
> 
> On Mon, 2003-01-27 at 10:44, Reggie Burnett wrote:
> > Well, certainly the driver could parse the sql and extract what it
> > thinks is the table name.  It just seems quite foreign to me to have
a
> > database engine go through the motions of determining column
location
> > and have ready access to all the metadata for all the columns in a
> > resultset and then intentionally leave all that out of the FE/BE.
> 
> I think the issue is that no one has yet proposed a consistent set of
> behaviour for this feature, particularly in the cases that Tom raised.
> If you would like this feature, I'd suggest that you outline some
> behaviour that everyone can agree upon.
> 
> Griping about "intentionally left out" features when the feature
itself
> is not even well defined doesn't strike me as very productive.
> 
> Cheers,
> 
> Neil
> --
> Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
> 
> 




---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Recursive unions

[Tom Lane]

"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> What was the result of the recursive unions thread?  I remember Tom maybe
> saying that the Redhat guys like the DB2 (SQL99) syntax the best, however
> was it said that that was going to be done by Redhat for 7.4?

It'll be looked at; whether it will be done in time for 7.4 is anyone's guess.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Specifying Rowtypes

[Stephan Szabo]

On Wed, 29 Jan 2003, Curt Sampson wrote:

> On Tue, 28 Jan 2003, Stephan Szabo wrote:
> > I believe only the column names and types are considered for purposes of
> > this.  Check constraints and the like defined on the column aren't applied
> > either.  I can see arguments for both ways since things like foreign keys
> > or the not yet supported check constraints with subselects would seem to
> > have not terribly meaningful results.
>
> Well, it might make sense to declare that you can't return anything that
> couldn't, in the current transaction, be inserted into that table.
>
> But easier, perhaps, would just be to provide the ability to add limited
> constraints to CREATE TYPE, and only honour the constranints that can be
> applied in a CREATE TYPE statement.

That's probably alot more reasonable.  The problem with saying anything
that couldn't be returned in the current transaction is that the state of
that by the time the function is done could be different than when the row
is constructed in the foreign key case (and check with subselect).  Then
there's also a question of before triggers because those are sometimes
used to force rows into a particular mold (set this field to this if it
doesn't meet some criteria).  Hmm, also we might have problems with
unique and primary key right now as well.

> > Although if you make the column on a domain and the domain has a
> > constraint it does seem to be applied.
>
> Hmmm. Interesting. This would be basically what I described above, then,
> wouldn't it, except it doesn't work for me (with types or tables):
>
> CREATE DOMAIN nonnull_int AS
>   int
>   DEFAULT 0
>   CONSTRAINT nonnull_int_not_null NOT NULL;
>
> CREATE TYPE t2_retval AS (
>   value1 nonnull_int,
>   value2 nonnull_int,
>   value3 nonnull_int
> );
>
> CREATE FUNCTION t2()
>   RETURNS SETOF t2_retval
> AS '
> DECLARE
>   retval t2_retval%ROWTYPE;
> BEGIN
>   SELECT INTO retval 1;
>   RETURN NEXT retval;
>   SELECT INTO retval 1, 2, 3;
>   RETURN NEXT retval;
>   SELECT INTO retval null, null, null;
>   RETURN NEXT retval;
>   RETURN;
> END
> ' LANGUAGE 'plpgsql';
>
> SELECT * FROM t2();
>
> ...produces rows with nulls in them.

That's a bug in pl/pgsql I believe.  An sql language
function (which is what I tried) requires you to cast
the value into the domain which fails due to the
constraint.  Presumably the same requirement should
hold here.


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] FW: [GENERAL] problems with dropped columns

[Tom Lane]

"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> This came to -general, it seems like a serious problem...

By and large, there's no support for dropped columns in function result
types.  Feel free to fix it ...

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [mail] Re: [HACKERS] Windows Build System

[Katie Ward]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane
> Sent: Wednesday, January 29, 2003 3:37 AM
> To: Curtis Faith
> Cc: 'Al Sutton'; 'Bruce Momjian'; [EMAIL PROTECTED]
> Subject: Re: [mail] Re: [HACKERS] Windows Build System
>
>
> "Curtis Faith" <[EMAIL PROTECTED]> writes:
> > If a developer can simply download the source, click on the Visual C++
> > project in the win32 directory and then build PostgreSQL, and they can
> > see that Windows is not the "poor stepchild" because the VC project is
> > well laid out, they will be more likely to use it for Windows projects
> > than MySQL which requires the CygWin tools (this means "really a Unix
> > product" to Windows developers).
>
> 
> In all honesty, I do not *want* Windows people to think that they're not
> running on the "poor stepchild" platform.If we go down that path,
> they'll start trying to run production databases on Windows, and then
> we'll get blamed for the instability of the platform, not to mention
> the likelihood that it ignores Unix semantics for fsync() and suchlike
> critical primitives.
>
> I have no objection to there being a Windows port that people can use
> to do SQL-client development on their laptops.  But let us please not
> confuse this with an industrial-strength solution; nor give any level
> of support that might lead others to make such confusion.
>
> The MySQL guys made the right choice here: they don't want to buy into
> making Windows a grade-A platform, either.
> 
>
>   regards, tom lane

Wow.  I've been listening to the pros and cons for a while, and they've been
really interesting.  However, to assume without ever using the native
Windows port that it is automatically a "poor stepchild" is unbelievable.

I believe that the port, as submitted, can be used as an industrial-strength
solution.  I challenge you all to prove me wrong, but until you do, please
lay off the assumptions.

Regards,
Katie Ward
Principle Developer
PeerDirect Corporation


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] client_encoding directive is ignored in postgresql.conf

[Tom Lane]

Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> + /* Flag to we need to initialize client encoding info */
> + static bool need_to_init_client_encoding = -1;

Surely that should be int, not bool.

> ! if (!PQsendQuery(conn, "begin; select 
>pg_client_encoding(); commit"))

Doesn't this break compatibility with pre-7.2 databases?  AFAICT that
function was introduced in 7.2.

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [mail] Re: [HACKERS] Windows Build System

[Vince Vielhaber]

On Wed, 29 Jan 2003, Katie Ward wrote:

> > 
> > In all honesty, I do not *want* Windows people to think that they're not
> > running on the "poor stepchild" platform.If we go down that path,
> > they'll start trying to run production databases on Windows, and then
> > we'll get blamed for the instability of the platform, not to mention
> > the likelihood that it ignores Unix semantics for fsync() and suchlike
> > critical primitives.
> >
> > I have no objection to there being a Windows port that people can use
> > to do SQL-client development on their laptops.  But let us please not
> > confuse this with an industrial-strength solution; nor give any level
> > of support that might lead others to make such confusion.
> >
> > The MySQL guys made the right choice here: they don't want to buy into
> > making Windows a grade-A platform, either.
> > 
> >
> > regards, tom lane
>
> Wow.  I've been listening to the pros and cons for a while, and they've been
> really interesting.  However, to assume without ever using the native
> Windows port that it is automatically a "poor stepchild" is unbelievable.
>
> I believe that the port, as submitted, can be used as an industrial-strength
> solution.  I challenge you all to prove me wrong, but until you do, please
> lay off the assumptions.

The only assumption I see being made here is this:

"I believe that the port, as submitted, can be used as an
industrial-strength solution."

I see no evidence to support this claim.  If you have this evidence,
feel free to share it with the rest of us.

Vince.
-- 
 Fast, inexpensive internet service 56k and beyond!  http://www.pop4.net/
   http://www.meanstreamradio.com   http://www.unknown-artists.com
 Internet radio: It's not file sharing, it's just radio.


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [mail] Re: [HACKERS] Windows Build System

[Dave Page]

> -Original Message-
> From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] 
> Sent: 29 January 2003 16:27
> To: Katie Ward
> Cc: Tom Lane; Curtis Faith; [EMAIL PROTECTED]
> Subject: Re: [mail] Re: [HACKERS] Windows Build System
> 
> 
> The only assumption I see being made here is this:
> 
> "I believe that the port, as submitted, can be used as an 
> industrial-strength solution."
> 
> I see no evidence to support this claim.  If you have this 
> evidence, feel free to share it with the rest of us.

I hammered the betas on a couple of test boxes running Windows XP and
.NET Server of various (pre)releases and found it to be rock solid,
performing comparably to my Linux based systems. The Cygwin version fell
over quite quickly under the same tests.

I'll admit my methods were not particularly scientific, but over the
last few weeks I've had far more grief from DB2 and SQL Server than I
did from the PostgreSQL native betas.

Regards, Dave.

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Specifying Rowtypes

[Tom Lane]

Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 29 Jan 2003, Curt Sampson wrote:
>> ...produces rows with nulls in them.

> That's a bug in pl/pgsql I believe.

Or a bug in the domain-constraints implementation.  plpgsql just
executes the input function for the datatype --- which is the same as
the input function for the underlying type.  There should probably be
some mechanism to make the input function for a domain type check the
domain's constraints.

[ thinks about it... ]  We added code to COPY to check domain
constraints on top of calling the type's input function, but I wonder
whether that wasn't the wrong way to go.  We'll have to hack everyplace
that calls an arbitrary input function, if we insist on that approach.

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [mail] Re: [HACKERS] Windows Build System

[Curtis Faith]

tom lane wrote:
> 
> In all honesty, I do not *want* Windows people to think that
> they're not running on the "poor stepchild" platform.

We should distinguish between "poor stepchild" from a client support
perspective and a production environment perspective.

What is the downside to supporting development of client products
better? That is what I am really suggesting.

If people are deciding what open-source database server they want to
use, Linux or FreeBSD is the obvious choice for the server OS. The kind
of people who are inclined to use PostgreSQL or MySQL will mostly NOT be
considering Windows servers.


> I have no objection to there being a Windows port that people
> can use to do SQL-client development on their laptops.  But 
> let us please not confuse this with an industrial-strength 
> solution; nor give any level of support that might lead 
> others to make such confusion.

All we can do is simply to make it clear that Windows
is not recommended for production server use and outline
all the reasons why Windows sucks for that purpose.

Beyond that, if people want to shoot themselves in the head, they will
do so and I don't see much point in trying to stop them.


> The MySQL guys made the right choice here: they don't want to
> buy into making Windows a grade-A platform, either. 


How does providing a native Windows executable that doesn't require
Cygwin accomplish your objective. It seems to me that you are going to
have the problem if you release a native version irrespective of the
issue at hand (Visual C++ project support).

I don't see how making it easier to build adds to this problem.

I also don't see how making it harder for Windows client developer to
adopt PostgreSQL helps anyone. 

I hate Microsoft and I don't like Windows, but I am forced to use it
because the software we need to run our business runs only on 
Windows. I use Unix whenever possible and whenever reliability is
required.

- Curtis

P.S. The lack of a real C++ client library that supports the most common
development environment out there is another problem that seriously
impedes Windows client developers.

I like libpqxx, Jeroen did a find job. However, one needs to 
jump through hoops to get it to run on Visual C++ 6.0 at
the moment.



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] JDBC drivers and streaming content

[Dave Cramer]

Chris,

It's already being done, you should post this to the jdbc list.

Dave
On Fri, 2003-01-24 at 11:07, Chris Smith wrote:
> I'm about to start implemention streaming of queries to the server in the
> pgsql jdbc drivers when PreparedStatement is used with setBinaryStream...
> but before I get started, since I've never contributed before, I wanted to
> run it by everyone.
> 
> I'm planning on making the following changes:
> 
> 1. In QueryExecutor.sendQuery, if an object in m_binds is a java.io.Reader,
> then instead of calling toString and sending that, I'll read and send the
> contents in 16K increments.
> 
> 2. In AbstractJdbc1Statement.setBinaryStream, instead of delegating to
> setBytes, I'll call bind directly, but send a custom java.io.Reader subclass
> (which adds the quotes and properly escapes the bytes and such) as the
> object.
> 
> A couple questions:
> 
> - There are a few constants that could probably be tuned for performance
> (ie, the size of the buffer used for streaming, and a threshold to avoid the
> streaming overhead for very short streams).  Is there a fairly standard way
> to handle this stuff in the JDBC drivers?  Should it be made configurable to
> the user?  Read from a properties file?  Stored in any specific class as a
> constant?
> 
> - It seems to be quite a pain that org.postgresql.core.Encoding works only
> with String, and can't copy into a provided char[] -- this will mean
> creating a large number of String objects during the streaming.  I could fix
> this easily with java.nio.CharsetEncoder, but it would make the code
> dependent on JDK 1.4.  Not desired?
> 
> - If there's a general dislike for runtime testing of object classes among
> the developer community, then I could, instead of special-casing Reader in
> sendQuery, wrap *all* PreparedStatement parameters in an interface that has
> a getReader method, and provide a default non-streaming implementation that
> uses StringReader.  This is more intrusive, but I'll go whichever way makes
> it more likely for the patch to be committed.
> 
> - Am I missing anything?  Is this harder than it seems?  Seems like someone
> would have done it already...
> 
> --
> www.designacourse.com
> The Easiest Way to Train Anyone... Anywhere.
> 
> Chris Smith - Lead Software Developer/Technical Trainer
> MindIQ Corporation
> 
> 
> ---(end of broadcast)---
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
-- 
Dave Cramer <[EMAIL PROTECTED]>
Cramer Consulting


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [mail] Re: [HACKERS] Windows Build System

[Justin Clift]

Curtis Faith wrote:

> If people are deciding what open-source database server they want to

use, Linux or FreeBSD is the obvious choice for the server OS. The kind
of people who are inclined to use PostgreSQL or MySQL will mostly NOT be
considering Windows servers.


For another perspective, we've been getting a few requests per day 
through the PostgreSQL Advocacy and Marketing site's request form along 
the lines of:

"Is there a license fee for using PostgreSQL?  We'd like to distribute 
it with our XYZ product that needs a database."

Probably about 4 or so per day like this at present.  A lot of the 
people sending these emails appear to have windows based products that 
need a database, and have heard of PostgreSQL being a database that they 
don't need to pay license fee's for.  They've kind of missed the point 
of Open Source from the purist point of view, but it's still working for 
them.  ;-)

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 try to be in the
first group; there was less competition there."
- Indira Gandhi


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [mail] Re: [HACKERS] Windows Build System

[Andrew Dunstan]

*sigh*

Often there isn't a choice of OS. If I am selling to a large enterprise
whose corporate standards say they will only run Windows in their data
center, my chances of getting them to make an exception are none. But my
chances of getting them to install Pg just for my application are far
greater. Would I prefer *nix? You betcha. Would I break a deal over it? No.
Would I prefer to be able to recommend Pg over, say, Oracle, or MS-SQL?
Absolutely. I'm not alone.

I don't care how it's built. I have a lot of sympathy for the folks saying
make the build process universal, rather than having a special one for
Windows. Requiring cygwin shouldn't be a big deal. You aren't going to get a
sudden flood of *nix-ignorant windows developers rushing in, no matter what
you do.

I've been mildly surprised and disappointed by the venom I detect in this
thread. I want to be able to recommend a single Db to my customers no matter
what OS they run. MySQL just doesn't do it, SAPdB is a nightmare, Pg is my
last hope other than a proprietary system. If you are an OpenSource zealot,
think of this as an opportunity to get some into places where it is often
anaethema.

cheers

andrew

- Original Message -
From: "Curtis Faith" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 29, 2003 11:54 AM
Subject: Re: [mail] Re: [HACKERS] Windows Build System


> tom lane wrote:
> > 
> > In all honesty, I do not *want* Windows people to think that
> > they're not running on the "poor stepchild" platform.
>
> We should distinguish between "poor stepchild" from a client support
> perspective and a production environment perspective.
>
> What is the downside to supporting development of client products
> better? That is what I am really suggesting.
>
> If people are deciding what open-source database server they want to
> use, Linux or FreeBSD is the obvious choice for the server OS. The kind
> of people who are inclined to use PostgreSQL or MySQL will mostly NOT be
> considering Windows servers.
>
>
> > I have no objection to there being a Windows port that people
> > can use to do SQL-client development on their laptops.  But
> > let us please not confuse this with an industrial-strength
> > solution; nor give any level of support that might lead
> > others to make such confusion.
>
> All we can do is simply to make it clear that Windows
> is not recommended for production server use and outline
> all the reasons why Windows sucks for that purpose.
>
> Beyond that, if people want to shoot themselves in the head, they will
> do so and I don't see much point in trying to stop them.
>
>
> > The MySQL guys made the right choice here: they don't want to
> > buy into making Windows a grade-A platform, either. 
>
> 
> How does providing a native Windows executable that doesn't require
> Cygwin accomplish your objective. It seems to me that you are going to
> have the problem if you release a native version irrespective of the
> issue at hand (Visual C++ project support).
>
> I don't see how making it easier to build adds to this problem.
>
> I also don't see how making it harder for Windows client developer to
> adopt PostgreSQL helps anyone. 
>
> I hate Microsoft and I don't like Windows, but I am forced to use it
> because the software we need to run our business runs only on
> Windows. I use Unix whenever possible and whenever reliability is
> required.
>
> - Curtis
>
> P.S. The lack of a real C++ client library that supports the most common
> development environment out there is another problem that seriously
> impedes Windows client developers.
>
> I like libpqxx, Jeroen did a find job. However, one needs to
> jump through hoops to get it to run on Visual C++ 6.0 at
> the moment.
>
>
>
> ---(end of broadcast)---
> TIP 4: Don't 'kill -9' the postmaster


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [mail] Re: [HACKERS] Windows Build System

[Vince Vielhaber]

On Wed, 29 Jan 2003, James Hubbard wrote:

> Vince Vielhaber wrote:
> > On Wed, 29 Jan 2003, Dave Page wrote:
> >
> >
> >>>The code's been available for what a week or two?  Do you
> >>>actually think that can be considered conclusive by any standard?
> >>
> >>Public beta testing (but closed source) has been going on for some
> >>months.
> >
> >
> > So you've been running these unscientific tests you're telling us
> > about being so successful for "some months"?
> >
> > Vince.
>
> I open my mouth and insert foot:  Where do I get any of these scientific
> tests to determine if the latest and greatest 7.3.x will not fall down on my
> favorite Unix?

If you're looking for a tool to test with, there was an announcement here
not too long ago for one.  But it goes beyond just running a test suite
against it.  Many of the available tools are designed to test what works
and how well it works.  Testing goes beyond that.  You want to know what
doesn't work, does the database return to a normal state if the unthinkable
happens (eg. Tom's suggestion of yanking the plug), how about loss of
network communications or sudden intermittant communication?  Or the
function that may not be checking its input that well - when it fails is
everything ok or did that transaction someone else was in the middle of
get blown away?

A gal that used to do MSDOS testing for MS (Jen something, don't recall
her last name) would pull a floppy out in the middle of read or write
and found a certain sequence would either hose the floppy, get the system
to reboot (don't recall the exact details, it's been YEARS).

Vince.
-- 
 Fast, inexpensive internet service 56k and beyond!  http://www.pop4.net/
   http://www.meanstreamradio.com   http://www.unknown-artists.com
 Internet radio: It's not file sharing, it's just radio.


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [mail] Re: [HACKERS] Windows Build System

[James Hubbard]

Vince Vielhaber wrote:



So you've been running these unscientific tests you're telling us
about being so successful for "some months"?

Vince.


I open my mouth and insert foot:  Where do I get any of these scientific
tests to determine if the latest and greatest 7.3.x will not fall down on my
favorite Unix?



If you're looking for a tool to test with, there was an announcement here
not too long ago for one.  But it goes beyond just running a test suite
against it.  Many of the available tools are designed to test what works
and how well it works.  Testing goes beyond that.  You want to know what
doesn't work, does the database return to a normal state if the unthinkable
happens (eg. Tom's suggestion of yanking the plug), how about loss of
network communications or sudden intermittant communication?  Or the
function that may not be checking its input that well - when it fails is
everything ok or did that transaction someone else was in the middle of
get blown away?

A gal that used to do MSDOS testing for MS (Jen something, don't recall
her last name) would pull a floppy out in the middle of read or write
and found a certain sequence would either hose the floppy, get the system
to reboot (don't recall the exact details, it's been YEARS).



I'm not disagreeing with you on testing.  I've seen the announcments. 
Justin Clift just posted them again.  But, as far as I've seen there are no 
real scientific tests that anyone here has posted.  I've seen the occasional 
post with db_bench.  You asked "To what standards?"  I've not seen any 
standards that are meaningful.  Maybe I'm just not looking.

Any benchmarks/tests that someone posts are going to be subjective anyway. 
 No one seems to be using the same tool.  The osdb is step in the right 
direction, but I've not really seen anyone using it.  The regressions are 
the only thing that I can see and run. It would be nice if there were a few 
people that had test setups that could post benchmarks/tests, so that we 
could see how things look for each release.
(i.e.:  on the 5GB test, it did this; when I cut the power and turned it 
back onn it did this and this.)

When I download, install, and use postgresql, I take it on faith that it 
will perform as the developers say that it does. Maybe this is a bad thing, 
but I don't think soMy use of it is very meager at the best so I don't 
have a lot to worry about.  If I had loads of data and mission critical apps 
I would probably test a lot, but I don't.

All I'm saying is to cut them some slack and give them some ideas to test 
until there is a really good testing/benchmarking tool that everyone can use 
that won't be as subjective.

I personally want this to succeed.  After having to use MySQL for a class 
project, I don't really want to use it again. I had to use because it was 
the only cross platform tool. Not everyone in the class was running linux or 
xBSD, so I had to go with MySQL.   From what I've seen, It looks like I'll 
have to anyhow because that's what many job ads are looking for.

I believe Oracle used the excuse that PostgreSQL was unproven, when they 
complained about its use for the .org registry. What we may think about 
Windows being fragile and being a piece of crap doesn't really matter. 
People are using it and it's at least doing they want.

I've probably not said this before, but I appreciate all the hard work that 
everyone puts into this project.

James Hubbard





---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [mail] Re: [HACKERS] Windows Build System

[Vince Vielhaber]

On Wed, 29 Jan 2003, Dave Page wrote:

>
>
> > -Original Message-
> > From: Vince Vielhaber [mailto:[EMAIL PROTECTED]]
> > Sent: 29 January 2003 16:27
> > To: Katie Ward
> > Cc: Tom Lane; Curtis Faith; [EMAIL PROTECTED]
> > Subject: Re: [mail] Re: [HACKERS] Windows Build System
> >
> >
> > The only assumption I see being made here is this:
> >
> > "I believe that the port, as submitted, can be used as an
> > industrial-strength solution."
> >
> > I see no evidence to support this claim.  If you have this
> > evidence, feel free to share it with the rest of us.
>
> I hammered the betas on a couple of test boxes running Windows XP and
> .NET Server of various (pre)releases and found it to be rock solid,
> performing comparably to my Linux based systems. The Cygwin version fell
> over quite quickly under the same tests.
>
> I'll admit my methods were not particularly scientific, but over the
> last few weeks I've had far more grief from DB2 and SQL Server than I
> did from the PostgreSQL native betas.

hammering the betas is a far cry from an "industrial-strength solution".

Vince.
-- 
 Fast, inexpensive internet service 56k and beyond!  http://www.pop4.net/
   http://www.meanstreamradio.com   http://www.unknown-artists.com
 Internet radio: It's not file sharing, it's just radio.


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [mail] Re: [HACKERS] Windows Build System

[Dave Page]

> -Original Message-
> From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] 
> Sent: 29 January 2003 16:36
> To: Dave Page
> Cc: Katie Ward; Tom Lane; Curtis Faith; [EMAIL PROTECTED]
> Subject: Re: [mail] Re: [HACKERS] Windows Build System
> 
> 
> On Wed, 29 Jan 2003, Dave Page wrote:
> 
> >
> >
> > > -Original Message-
> > > From: Vince Vielhaber [mailto:[EMAIL PROTECTED]]
> > > Sent: 29 January 2003 16:27
> > > To: Katie Ward
> > > Cc: Tom Lane; Curtis Faith; [EMAIL PROTECTED]
> > > Subject: Re: [mail] Re: [HACKERS] Windows Build System
> > >
> > >
> > > The only assumption I see being made here is this:
> > >
> > > "I believe that the port, as submitted, can be used as an 
> > > industrial-strength solution."
> > >
> > > I see no evidence to support this claim.  If you have 
> this evidence, 
> > > feel free to share it with the rest of us.
> >
> > I hammered the betas on a couple of test boxes running 
> Windows XP and 
> > .NET Server of various (pre)releases and found it to be rock solid, 
> > performing comparably to my Linux based systems. The Cygwin version 
> > fell over quite quickly under the same tests.
> >
> > I'll admit my methods were not particularly scientific, but 
> over the 
> > last few weeks I've had far more grief from DB2 and SQL 
> Server than I 
> > did from the PostgreSQL native betas.
> 
> hammering the betas is a far cry from an "industrial-strength 
> solution".

Have you a better suggestion? Seems a bit catch 22 if testing won't
prove it's good and we can't use it until we know it's good... Still,
industrial strength testing or not, it's more reliable than the SQL 2000
and DB2 installations I have here.

Regards, Dave.

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [mail] Re: [HACKERS] Windows Build System

[cbbrowne]

Justin Clift wrote:
> For another perspective, we've been getting a few requests per day 
> through the PostgreSQL Advocacy and Marketing site's request form along 
> the lines of:
> 
> "Is there a license fee for using PostgreSQL?  We'd like to distribute 
> it with our XYZ product that needs a database."
> 
> Probably about 4 or so per day like this at present.  A lot of the 
> people sending these emails appear to have windows based products that 
> need a database, and have heard of PostgreSQL being a database that they 
> don't need to pay license fee's for.  They've kind of missed the point 
> of Open Source from the purist point of view, but it's still working for 
> them.  ;-)

If they are:
 a) not clueful enough to actually look at the license, and
 b) looking at it from the purely selfish perspective of "not having to
pay license fees,"
then are they /truly/ people where it is useful to put effort into being
helpful?

Furthermore, if their lawyers are incapable of reading the license and
explaining to them "You don't have to pay," I'd suggest the thought that
maybe they have bigger problems than you can possibly solve for them.

The great security quote of recent days is thus:
  "If you spend more on coffee than on IT security, then you will be
  hacked." -- Richard Clarke

The analagous thing might be:

"If you spend more on coffee than you do on getting proper legal advice
about software licenses, then it's just possible that you might do
something DOWNRIGHT STUPID and get yourself in a whole barrel of legal
hot water."

If these people are incapable of reading software licenses, and haven't
any competent legal counsel to to do it for them, you've got to wonder
if they are competent to sell licenses to their own software.  I
seriously doubt that they are.

Furthermore, I'm not at all sure that it is wise for you to even /try/
to give them any guidance in this, beyond giving them a URL to the
license, and saying "Have your lawyer read this."  If you start giving
them interpretations of the license, that smacks of "giving legal
advice," and bar associations tend to frown on that.
--
If this was helpful,  rate me
http://cbbrowne.com/info/
"Interfaces keep things tidy, but don't accelerate growth: functions
do." -- Alan Perlis

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [mail] Re: [HACKERS] Windows Build System

[Vince Vielhaber]

On Wed, 29 Jan 2003, Dave Page wrote:

> > hammering the betas is a far cry from an "industrial-strength
> > solution".
>
> Have you a better suggestion? Seems a bit catch 22 if testing won't
> prove it's good and we can't use it until we know it's good... Still,
> industrial strength testing or not, it's more reliable than the SQL 2000
> and DB2 installations I have here.

Well you have a beta running, load it up with data and let a few hundred
clients loose on it.  I've seen win2k BSOD with less stress than that.

Vince.
-- 
 Fast, inexpensive internet service 56k and beyond!  http://www.pop4.net/
   http://www.meanstreamradio.com   http://www.unknown-artists.com
 Internet radio: It's not file sharing, it's just radio.


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [mail] Re: [HACKERS] Windows Build System

[Vince Vielhaber]

On Wed, 29 Jan 2003, Katie Ward wrote:

> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Vince Vielhaber
> > Sent: Wednesday, January 29, 2003 11:45 AM
> > To: Dave Page
> > Cc: Katie Ward; Tom Lane; Curtis Faith; [EMAIL PROTECTED]
> > Subject: Re: [mail] Re: [HACKERS] Windows Build System
> >
> >
> > On Wed, 29 Jan 2003, Dave Page wrote:
> >
> > > > hammering the betas is a far cry from an "industrial-strength
> > > > solution".
> > >
> > > Have you a better suggestion? Seems a bit catch 22 if testing won't
> > > prove it's good and we can't use it until we know it's good... Still,
> > > industrial strength testing or not, it's more reliable than the SQL 2000
> > > and DB2 installations I have here.
> >
> > Well you have a beta running, load it up with data and let a few hundred
> > clients loose on it.  I've seen win2k BSOD with less stress than that.
> >
> > Vince.
>
> We did that as part of our internal testing, using the ATM database and a
> dual-processor machine.  We tried both with clients connecting and
> disconnection quickly, and with large numbers of clients that stayed
> connected for a while, all extremely active.  Native Win32 performed
> comparably with running the same test on comparable machines on LINUX.
> Nothing crashed.

The code's been available for what a week or two?  Do you actually
think that can be considered conclusive by any standard?

Vince.
-- 
 Fast, inexpensive internet service 56k and beyond!  http://www.pop4.net/
   http://www.meanstreamradio.com   http://www.unknown-artists.com
 Internet radio: It's not file sharing, it's just radio.


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [mail] Re: [HACKERS] Windows Build System

[Tom Lane]

"Dave Page" <[EMAIL PROTECTED]> writes:
> I'll admit my methods were not particularly scientific, but over the
> last few weeks I've had far more grief from DB2 and SQL Server than I
> did from the PostgreSQL native betas.

My gripe had to do with questioning the reliability of the platform, not
of the Postgres port ;-).

Aside from load testing as suggested by Vince, I'd be interested to hear
what happens when you pull the power cord under load (repeatedly).  This
would give some evidence about the robustness of the Windows filesystem
and its ability to emulate Unix sync semantics.

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [mail] Re: [HACKERS] Windows Build System

[Dave Page]

> -Original Message-
> From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] 
> Sent: 29 January 2003 16:45
> To: Dave Page
> Cc: Katie Ward; Tom Lane; Curtis Faith; [EMAIL PROTECTED]
> Subject: Re: [mail] Re: [HACKERS] Windows Build System
> 
> 
> On Wed, 29 Jan 2003, Dave Page wrote:
> 
> > > hammering the betas is a far cry from an "industrial-strength 
> > > solution".
> >
> > Have you a better suggestion? Seems a bit catch 22 if testing won't 
> > prove it's good and we can't use it until we know it's 
> good... Still, 
> > industrial strength testing or not, it's more reliable than the SQL 
> > 2000 and DB2 installations I have here.
> 
> Well you have a beta running, load it up with data and let a 
> few hundred clients loose on it.  I've seen win2k BSOD with 
> less stress than that.

That's what I was doing, loading it up with hundreds of connections from
other boxes, using osdb and pgbench. I'm not saying it's bug free, or
that Win2K won't crash under it, but it performed well for me - better
than 2 of the leading commercial databases. 

I agree with Katie, dismissing a largely untested product because it
runs on Windows is not a good thing. Yes, Windows can BSOD, but when a
system is built on good hardware (for which good quality drivers are
available), and configured well it can be as reliable, if not more so
than some versions of Linux that have been released.

I would be interested to know how many windows servers those that are
against a windows port of PostgreSQL have or do manage, and how
experienced they are with that platform...

Regards, Dave.


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] client_encoding directive is ignored in

[Tatsuo Ishii]

> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > + /* Flag to we need to initialize client encoding info */
> > + static bool need_to_init_client_encoding = -1;
> 
> Surely that should be int, not bool.

Oops. Will fix.

> > !   if (!PQsendQuery(conn, "begin; select 
>pg_client_encoding(); commit"))
> 
> Doesn't this break compatibility with pre-7.2 databases?  AFAICT that
> function was introduced in 7.2.

Yes, but there seems no other way to solve the problem and I thought we
do not guarantee the compatibilty between 7.3 frontend and pre 7.3 servers.
--
Tatsuo Ishii

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

[HACKERS] v7.2.4 bundled ...

[Marc G. Fournier]

Morning all ...

  I jsut bundled up v7.2.4 with all the recent security fixes ... can a
few ppl do some regression tests and report back before I announce in the
morning?  I did a configure and build here and all looks fine, but some
confirmations is always nice ;)



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

[HACKERS] Linux.conf.au 2003 Report

[Christopher Kings-Lynne]

Linux.conf.au Report


The Linux.conf.au is an international Linux/Open Source event that attracts
lots of international speakers.  Total conf attendance was around 360, maybe
even 400 I think.

Gavin Sherry was speaking at this particular conf, and I attended as a
hobbyist.

PostgreSQL got a reasonable amount of attention, particularly since there
were no representatives from other database products there.

Some pics of our PostgreSQL BOF and the Perth Bell Tower:
http://www.zip.com.au/~swm/lca2003
(Gavin is the beardy looking dude 3rd from the left :)  I'm taking the
photo.)

These are the main questions we where asked, or features that were
requested:

* Replication, replication, replication!

- We told them that there are a few solutions, none of them are particularly
great.  Gavin got all sorts of ideas about log shipping.

* IPV6 data types

- Apparently there are some ISPs in some countries that have started to bill
people for IPV6 bandwidth, and the lack of IPV6 address types is hurting
them.

* Collisions in auto-generated names.

- The standard table modification tactic (that I also use) or renaming table
to *_old and creating new one breaks because the primary key of the new
table is assigned the same name as the PK of the old, causing CREATE TABLE
to fail.  This is really annoying.  I think that auto-generated names should
never collide.

* Problem:  person has large database with 4 or 5 humungous tables that they
aren't interested in backing up.  However, they want to back up the rest.

- I suggested that if pg_dump could dump individual schemas, then they could
move their 'don't backup' tables to another schema, and just dump the other
one.

We found out all sorts of interesting places that PostgreSQL is being used:
a large Australian Telco, several restaurants in the Perth area, the Debian
inventory system and the Katie revision control system.  It is also being
evaluated for process control analysis at a steel plant.  Maybe we should
chase some people for case studies?

Chris Kings-Lynne


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] [pgsql-advocacy] Linux.conf.au 2003 Report

[Neil Conway]

On Wed, 2003-01-29 at 21:49, Christopher Kings-Lynne wrote:
> * IPV6 data types

Looks like this will be in 7.4, in one form or another.

> - The standard table modification tactic (that I also use) or renaming table
> to *_old and creating new one breaks because the primary key of the new
> table is assigned the same name as the PK of the old, causing CREATE TABLE
> to fail.  This is really annoying.  I think that auto-generated names should
> never collide.

Can this be accomplished without making auto-generated names ugly? And
if not, is it worth the trade-off?

> - I suggested that if pg_dump could dump individual schemas, then they could
> move their 'don't backup' tables to another schema, and just dump the other
> one.

FYI, I submitted a patch for this a couple weeks ago (although it hasn't
been applied yet...) -- it should be in 7.4

Cheers,

Neil
-- 
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC




---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] v7.2.4 bundled ...

[Rod Taylor]

>   I jsut bundled up v7.2.4 with all the recent security fixes ... can a
> few ppl do some regression tests and report back before I announce in the
> morning?  I did a configure and build here and all looks fine, but some
> confirmations is always nice ;)

Updated to tag REL7_2_4 on FreeBSD 4.7 and cannot compile it.  gram.y
errors complaining: invalid character: ','.

bash-2.05b$ bison --version
bison (GNU Bison) 1.75
Written by Robert Corbett and Richard Stallman.



-- 
Rod Taylor <[EMAIL PROTECTED]>

PGP Key: http://www.rbt.ca/rbtpub.asc



signature.asc
Description: This is a digitally signed message part

Re: [mail] Re: [HACKERS] Windows Build System

[Dave Page]

> -Original Message-
> From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] 
> Sent: 29 January 2003 16:57
> To: Katie Ward
> Cc: Dave Page; Tom Lane; Curtis Faith; [EMAIL PROTECTED]
> Subject: RE: [mail] Re: [HACKERS] Windows Build System
> 
> 
> The code's been available for what a week or two?  Do you 
> actually think that can be considered conclusive by any standard?

Public beta testing (but closed source) has been going on for some
months.

Regards, Dave.

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] [pgsql-advocacy] Linux.conf.au 2003 Report

[Justin Clift]

Christopher Kings-Lynne wrote:


We found out all sorts of interesting places that PostgreSQL is being used:
a large Australian Telco, several restaurants in the Perth area, the Debian
inventory system and the Katie revision control system.  It is also being
evaluated for process control analysis at a steel plant.  Maybe we should
chase some people for case studies?


Definitely.  Forgot to mention this before, but my gf (Carol Ioanni 
<[EMAIL PROTECTED]>) is taking the next couple of weeks to 
assist us pretty much "full time" as thankfully she has some spare time 
on her hands for a bit.  :)

She's been pointed towards our urgent need for Case Studies and has 
already begun working with a couple of places to assist them in getting 
them done.  We have a "standard waiver" that places need to sign so 
we're legally in the clear, and a *very* professionally created Case 
Study Worksheet (donated by Sales.Org for the use of all Free / Open 
Source Software projects) that places work through and which gives us a 
very presentable result.

Carol should be a real expert at making Case Studies pretty soon now is 
my guess, as that's all she's going to be doing.  ;-)

If people could ask the places they have contact with, and whom are 
using PostgreSQL in significant ways, if they'd be happy to be a 
reference PostgreSQL Case Study, that would be great.  Some places might 
ask what's in it for them (it's been happening now and again), and 
pretty much we can tangibly say they'll be included in the PostgreSQL 
Advocacy and Marketing site's "Case Studies" section, and we'll be 
making downloadable PDF's of the Case Studies as well so that people can 
distribute them as needed (i.e. to their CIOs/CEOs/CTOs/etc).

For all places that are happy to get involved in this way, please email 
Carol directly and bring her into the conversation so that we can get 
them using the same Case Study Worksheet, get the waiver signed, and 
start grouping and placing the Case Studies appropriately in the Case 
Studies section.

For further background info, the present page views per day of the 
Advocacy and Marketing site from when the new PostgreSQL portal page 
went live (broken into week long groupings) are:

 5/Jan/03: 2203: +++
 6/Jan/03: 3983: +++
 7/Jan/03: 4493: ++
 8/Jan/03: 4889: +
 9/Jan/03: 4364: ++
10/Jan/03: 3513: 
11/Jan/03: 2112: +++

12/Jan/03: 2735: +++
13/Jan/03: 4405: ++
14/Jan/03: 4226: +
15/Jan/03: 3752: ++
16/Jan/03: 3467: 
17/Jan/03: 3808: ++
18/Jan/03: 1932: +

19/Jan/03: 1777: 
20/Jan/03: 3641: +
21/Jan/03: 4025: +++
22/Jan/03: 3643: +
23/Jan/03: 3310: +++
24/Jan/03: 4242: +
25/Jan/03: 2749: +++

26/Jan/03: 2834: +++
27/Jan/03: 4010: +++
28/Jan/03: 4081: 

Not huge, but not bad for the first version of the site either.  Since 
the Advocacy and Marketing site isn't very large, it means the case 
studies added there generally do get looked at.

Regards and best wishes,

Justin Clift

Chris Kings-Lynne


--
"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 try to be in the
first group; there was less competition there."
- Indira Gandhi


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [mail] Re: [HACKERS] Windows Build System

[Ron Mayer]

Cool irony in the automated .sig on the mailinglist software...

On Wed, 29 Jan 2003, Vince Vielhaber wrote:
> ... 
> hammering the betas is a far cry from an "industrial-strength solution".
> ...
> TIP 4: Don't 'kill -9' the postmaster

Sounds like you're basically saying is 

   _do_ 'kill -9' the postmaster...

and make sure it recovers gracefully when testing for an "industrial-
strength solution".


   Ron


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] v7.2.4 bundled ...

[Tom Lane]

Rod Taylor <[EMAIL PROTECTED]> writes:
> Updated to tag REL7_2_4 on FreeBSD 4.7 and cannot compile it.  gram.y
> errors complaining: invalid character: ','.

> bash-2.05b$ bison --version
> bison (GNU Bison) 1.75

We just had that discussion on pgcore.  The 7.2 grammar was developed
against bison 1.28; it works with warnings against bison 1.35, but bison
1.75 just flat rejects it (not for any significant reason, but just
because they decided to get anal-retentive about whether they'd allow
commas in keyword lists).

We could update the 7.2 grammar and compile it with the latest bison,
but we were worried about whether we might introduce any subtle problems
if we did.  The 7.2 branch has received zero testing with bison 1.75.

ISTM that the eve of what'll probably be our last dot-release for 7.2
is not the time to drop a new bison into its toolchain.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] v7.2.4 bundled ...

[Tom Lane]

"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>   I jsut bundled up v7.2.4 with all the recent security fixes ... can a
> few ppl do some regression tests and report back before I announce in the
> morning?  I did a configure and build here and all looks fine, but some
> confirmations is always nice ;)

Passes regression tests here (HPUX 10.20)...

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] v7.2.4 bundled ...

[Christopher Kings-Lynne]

Where do I get it from?

I can't see it on any of the FTP sites...

Chris

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Marc G. Fournier
> Sent: Thursday, 30 January 2003 10:00 AM
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] v7.2.4 bundled ...
> 
> 
> 
> Morning all ...
> 
>   I jsut bundled up v7.2.4 with all the recent security fixes ... can a
> few ppl do some regression tests and report back before I announce in the
> morning?  I did a configure and build here and all looks fine, but some
> confirmations is always nice ;)
> 
> 
> 
> ---(end of broadcast)---
> TIP 4: Don't 'kill -9' the postmaster
> 


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [mail] Re: [HACKERS] Windows Build System

[Kevin Brown]

Tom Lane wrote:
> "Curtis Faith" <[EMAIL PROTECTED]> writes:
> > If a developer can simply download the source, click on the Visual C++
> > project in the win32 directory and then build PostgreSQL, and they can
> > see that Windows is not the "poor stepchild" because the VC project is
> > well laid out, they will be more likely to use it for Windows projects
> > than MySQL which requires the CygWin tools (this means "really a Unix
> > product" to Windows developers).
> 
> 
> In all honesty, I do not *want* Windows people to think that they're not
> running on the "poor stepchild" platform.If we go down that path,
> they'll start trying to run production databases on Windows, and then
> we'll get blamed for the instability of the platform, not to mention
> the likelihood that it ignores Unix semantics for fsync() and suchlike
> critical primitives.

Unless this concern is the result of experience (with, say, some
versions of Linux or whatnot), then I'd be more inclined to take a
"try it and see" attitude.

I do think it's quite appropriate to make the world aware that
PostgreSQL under Windows is not likely to be as dependable as
PostgreSQL under other Unix platforms, if only because the underlying
platform isn't as stable.

The fsync() issue and others like it can hopefully be settled through
testing.  Frankly, I will be surprised if it doesn't work (but not
*too* surprised :-).

> I have no objection to there being a Windows port that people can use
> to do SQL-client development on their laptops.  But let us please not
> confuse this with an industrial-strength solution; nor give any level
> of support that might lead others to make such confusion.

I don't believe the level of support this group provides has anything
to do with whether or not others will regard PostgreSQL on Windows to
be an industrial strength solution.  Only their experience will
determine that.  Because PostgreSQL doesn't have a huge marketing arm,
its reputation is built upon word of mouth, which is something that
only comes from experience.

You're assuming that if PostgreSQL is made available under Windows
such that it can be run as a service, people who deploy it will
immediately assume that it's an industrial strength solution.  I think
that assumption is faulty, because in reality people out there in the
real world are reluctant to deploy PostgreSQL under *Unix* as an
industrial strength solution despite its high reliability.  Otherwise
PostgreSQL would be a LOT more popular than it is.

It takes time and experience for people to be convinced that something
is industrial-strength, and the Windows port of PostgreSQL is no
exception.

Perhaps your real concern here is that a port of PostgreSQL to Windows
might negatively impact the overall reputation of PostgreSQL due to
the fragility of Windows.  But I don't think that's really much of a
concern: I don't believe the overall reputation of Oracle suffered due
to its Windows port, for instance.  I think most people who really
care about such things are aware that Windows as a platform isn't as
reliable as Unix and take that into account when judging the
reliability of a deployed solution.

For judging the reliability PostgreSQL under Windows, what would
matter would be how it stacks up against other database engines
running under Windows.  In other words, take Windows out of the
comparison equation.  If PostgreSQL under Windows is at least as fast,
solid, etc., as MS-SQL, DB/2, or Oracle under Windows, then people
will rightly think of PostgreSQL as an industrial-strength solution
and the reputation of PostgreSQL will be secure despite the failings
of the platform relative to Unix.

Bottom line: put tons of disclaimers about the likely reliability of
the Windows port in the documentation if you'd like, but don't let
these concerns prevent any action with respect to doing a proper
Windows port.


-- 
Kevin Brown   [EMAIL PROTECTED]

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Linux.conf.au 2003 Report

[Tom Lane]

"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Linux.conf.au Report
> [ much snipped ]

> * IPV6 data types
> - Apparently there are some ISPs in some countries that have started to bill
> people for IPV6 bandwidth, and the lack of IPV6 address types is hurting
> them.

Yeah.  This is a pretty self-contained problem, it just needs someone
who's motivated to work on it.  Mostly what we need is to understand how
we want to extend the previously-agreed-to I/O behaviors for IPv4 inet
and cidr types into the v6 domain.  (Or should we back up and ask if the
inet/cidr division still makes sense in the v6 world?  I hope so, but
if not we should face up to it...)

> ...  Maybe we should
> chase some people for case studies?

U betcha ... we were just getting pestered for more of those ...

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Linux.conf.au 2003 Report

[Christopher Kings-Lynne]

> Yeah.  This is a pretty self-contained problem, it just needs someone
> who's motivated to work on it.  Mostly what we need is to understand how
> we want to extend the previously-agreed-to I/O behaviors for IPv4 inet
> and cidr types into the v6 domain.  (Or should we back up and ask if the
> inet/cidr division still makes sense in the v6 world?  I hope so, but
> if not we should face up to it...)

Maybe we should create a new type 'inet6'???

Chris


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Linux.conf.au 2003 Report

[Tom Lane]

"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Maybe we should create a new type 'inet6'???

I'd lean towards allowing the existing inet and cidr types to store both
v4 and v6 addresses, if at all possible.  Is there a good motivation for
doing otherwise?

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] v7.2.4 bundled ...

[Magnus Naeslund(f)]

Redhat 6.2
Linux gserver1 2.4.19-pre6 #4 Thu Apr 11 07:17:39 CEST 2002 alpha
unknown
All 79 tests passed.

Magnus


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [mail] Re: [HACKERS] Windows Build System

[Dave Page]

> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]] 
> Sent: 29 January 2003 16:57
> To: Dave Page
> Cc: Vince Vielhaber; Katie Ward; Curtis Faith; 
> [EMAIL PROTECTED]
> Subject: Re: [mail] Re: [HACKERS] Windows Build System 
> 
> 
> "Dave Page" <[EMAIL PROTECTED]> writes:
> > I'll admit my methods were not particularly scientific, but 
> over the 
> > last few weeks I've had far more grief from DB2 and SQL 
> Server than I 
> > did from the PostgreSQL native betas.
> 
> My gripe had to do with questioning the reliability of the 
> platform, not of the Postgres port ;-).
> 
> Aside from load testing as suggested by Vince, I'd be 
> interested to hear what happens when you pull the power cord 
> under load (repeatedly).  This would give some evidence about 
> the robustness of the Windows filesystem and its ability to 
> emulate Unix sync semantics.

OK, I can maybe do some testing on that next week (I'm off for a few
days from today). Is there anything in particular I should look out for,
or that you would want tested?

Katie, can I get the latest build from anywhere?

Regards, Dave.

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] v7.2.4 bundled ...

[Tom Lane]

"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Where do I get it from?
> I can't see it on any of the FTP sites...

Not all the mirrors have updated yet, but I see it at
ftp://ftp9.us.postgresql.org/pub/mirrors/postgresql/source/v7.2.4/
for one ...

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] v7.2.4 bundled ...

[Kevin Brown]

Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Updated to tag REL7_2_4 on FreeBSD 4.7 and cannot compile it.  gram.y
> > errors complaining: invalid character: ','.
> 
> > bash-2.05b$ bison --version
> > bison (GNU Bison) 1.75
> 
> We just had that discussion on pgcore.  The 7.2 grammar was developed
> against bison 1.28; it works with warnings against bison 1.35, but bison
> 1.75 just flat rejects it (not for any significant reason, but just
> because they decided to get anal-retentive about whether they'd allow
> commas in keyword lists).
> 
> We could update the 7.2 grammar and compile it with the latest bison,
> but we were worried about whether we might introduce any subtle problems
> if we did.  The 7.2 branch has received zero testing with bison 1.75.
> 
> ISTM that the eve of what'll probably be our last dot-release for 7.2
> is not the time to drop a new bison into its toolchain.

For what it's worth, I've fixed all the errors in the 7.2.4 gram.y
file that bison 1.75 complained and then re-ran bison 1.35 against it,
then compared that with the output that the same version of bison
generated from the original grammar file.  The only differences were
references to line numbers -- everything else is identical.

So if any problems occur from using bison 1.75, they will be either
due to bugs in that version of bison or due to our dependence on a bug
in earlier versions, or something like that.

I'm attaching a patch for 7.2.4's parser/gram.y that fixes all of
bison 1.75's complaints.  Since the output of bison 1.35 is
essentially identical between the original and this, I don't see any
reason we shouldn't include the fix in the 7.2.4 release, as long as
we include a warning in the release notes that we haven't done any
real testing with a build against bison 1.75 (or later).


-- 
Kevin Brown   [EMAIL PROTECTED]

--- gram.y.orig Wed Jan 29 22:39:31 2003
+++ gram.y  Wed Jan 29 22:43:33 2003
@@ -129,33 +129,33 @@
InsertStmt  *istmt;
 }
 
-%typestmt,
-   AlterGroupStmt, AlterSchemaStmt, AlterTableStmt, AlterUserStmt,
-   AnalyzeStmt,
-   ClosePortalStmt, ClusterStmt, CommentStmt, ConstraintsSetStmt,
-   CopyStmt, CreateAsStmt, CreateGroupStmt, CreatePLangStmt,
-   CreateSchemaStmt, CreateSeqStmt, CreateStmt, CreateTrigStmt,
-   CreateUserStmt, CreatedbStmt, CursorStmt, DefineStmt, DeleteStmt,
-   DropGroupStmt, DropPLangStmt, DropSchemaStmt, DropStmt, DropTrigStmt,
-   DropUserStmt, DropdbStmt, ExplainStmt, FetchStmt,
-   GrantStmt, IndexStmt, InsertStmt, ListenStmt, LoadStmt, LockStmt,
-   NotifyStmt, OptimizableStmt, ProcedureStmt, ReindexStmt,
-   RemoveAggrStmt, RemoveFuncStmt, RemoveOperStmt,
-   RenameStmt, RevokeStmt, RuleActionStmt, RuleActionStmtOrEmpty,
-   RuleStmt, SelectStmt, TransactionStmt, TruncateStmt,
-   UnlistenStmt, UpdateStmt, VacuumStmt, VariableResetStmt,
-   VariableSetStmt, VariableShowStmt, ViewStmt, CheckPointStmt
+%typestmt
+   AlterGroupStmt AlterSchemaStmt AlterTableStmt AlterUserStmt
+   AnalyzeStmt
+   ClosePortalStmt ClusterStmt CommentStmt ConstraintsSetStmt
+   CopyStmt CreateAsStmt CreateGroupStmt CreatePLangStmt
+   CreateSchemaStmt CreateSeqStmt CreateStmt CreateTrigStmt
+   CreateUserStmt CreatedbStmt CursorStmt DefineStmt DeleteStmt
+   DropGroupStmt DropPLangStmt DropSchemaStmt DropStmt DropTrigStmt
+   DropUserStmt DropdbStmt ExplainStmt FetchStmt
+   GrantStmt IndexStmt InsertStmt ListenStmt LoadStmt LockStmt
+   NotifyStmt OptimizableStmt ProcedureStmt ReindexStmt
+   RemoveAggrStmt RemoveFuncStmt RemoveOperStmt
+   RenameStmt RevokeStmt RuleActionStmt RuleActionStmtOrEmpty
+   RuleStmt SelectStmt TransactionStmt TruncateStmt
+   UnlistenStmt UpdateStmt VacuumStmt VariableResetStmt
+   VariableSetStmt VariableShowStmt ViewStmt CheckPointStmt
 
-%typeselect_no_parens, select_with_parens, select_clause,
+%typeselect_no_parens select_with_parens select_clause
simple_select
 
 %type alter_column_default
 %type drop_behavior
 
-%typecreatedb_opt_list, createdb_opt_item
+%typecreatedb_opt_list createdb_opt_item
 
-%typeopt_lock, lock_type
-%type opt_force, opt_or_replace
+%typeopt_lock lock_type
+%type opt_force opt_or_replace
 
 %typeuser_list
 
@@ -165,7 +165,7 @@
 %typeOptUserList
 %type  OptUserElem
 
-%type TriggerActionTime, TriggerForSpec, opt_trusted, opt_procedural
+%type TriggerActionTime TriggerForSpec opt_trusted opt_procedural
 %type opt_lancompiler
 
 %type OptConstrFromTable
@@ -17

Re: [HACKERS] v7.2.4 bundled ...

[Kevin Brown]

Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Updated to tag REL7_2_4 on FreeBSD 4.7 and cannot compile it.  gram.y
> > errors complaining: invalid character: ','.
> 
> > bash-2.05b$ bison --version
> > bison (GNU Bison) 1.75
> 
> We just had that discussion on pgcore.  The 7.2 grammar was developed
> against bison 1.28; it works with warnings against bison 1.35, but bison
> 1.75 just flat rejects it (not for any significant reason, but just
> because they decided to get anal-retentive about whether they'd allow
> commas in keyword lists).
> 
> We could update the 7.2 grammar and compile it with the latest bison,
> but we were worried about whether we might introduce any subtle problems
> if we did.  The 7.2 branch has received zero testing with bison 1.75.
> 
> ISTM that the eve of what'll probably be our last dot-release for 7.2
> is not the time to drop a new bison into its toolchain.

Ooops.  Last patch wasn't done using CVS diff.  This one is, in case
it matters...


-- 
Kevin Brown   [EMAIL PROTECTED]

Index: gram.y
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/parser/gram.y,v
retrieving revision 2.276.2.1
diff -u -d -r2.276.2.1 gram.y
--- gram.y  2002/03/09 17:41:04 2.276.2.1
+++ gram.y  2003/01/30 06:55:25
@@ -129,33 +129,33 @@
InsertStmt  *istmt;
 }
 
-%typestmt,
-   AlterGroupStmt, AlterSchemaStmt, AlterTableStmt, AlterUserStmt,
-   AnalyzeStmt,
-   ClosePortalStmt, ClusterStmt, CommentStmt, ConstraintsSetStmt,
-   CopyStmt, CreateAsStmt, CreateGroupStmt, CreatePLangStmt,
-   CreateSchemaStmt, CreateSeqStmt, CreateStmt, CreateTrigStmt,
-   CreateUserStmt, CreatedbStmt, CursorStmt, DefineStmt, DeleteStmt,
-   DropGroupStmt, DropPLangStmt, DropSchemaStmt, DropStmt, DropTrigStmt,
-   DropUserStmt, DropdbStmt, ExplainStmt, FetchStmt,
-   GrantStmt, IndexStmt, InsertStmt, ListenStmt, LoadStmt, LockStmt,
-   NotifyStmt, OptimizableStmt, ProcedureStmt, ReindexStmt,
-   RemoveAggrStmt, RemoveFuncStmt, RemoveOperStmt,
-   RenameStmt, RevokeStmt, RuleActionStmt, RuleActionStmtOrEmpty,
-   RuleStmt, SelectStmt, TransactionStmt, TruncateStmt,
-   UnlistenStmt, UpdateStmt, VacuumStmt, VariableResetStmt,
-   VariableSetStmt, VariableShowStmt, ViewStmt, CheckPointStmt
+%typestmt
+   AlterGroupStmt AlterSchemaStmt AlterTableStmt AlterUserStmt
+   AnalyzeStmt
+   ClosePortalStmt ClusterStmt CommentStmt ConstraintsSetStmt
+   CopyStmt CreateAsStmt CreateGroupStmt CreatePLangStmt
+   CreateSchemaStmt CreateSeqStmt CreateStmt CreateTrigStmt
+   CreateUserStmt CreatedbStmt CursorStmt DefineStmt DeleteStmt
+   DropGroupStmt DropPLangStmt DropSchemaStmt DropStmt DropTrigStmt
+   DropUserStmt DropdbStmt ExplainStmt FetchStmt
+   GrantStmt IndexStmt InsertStmt ListenStmt LoadStmt LockStmt
+   NotifyStmt OptimizableStmt ProcedureStmt ReindexStmt
+   RemoveAggrStmt RemoveFuncStmt RemoveOperStmt
+   RenameStmt RevokeStmt RuleActionStmt RuleActionStmtOrEmpty
+   RuleStmt SelectStmt TransactionStmt TruncateStmt
+   UnlistenStmt UpdateStmt VacuumStmt VariableResetStmt
+   VariableSetStmt VariableShowStmt ViewStmt CheckPointStmt
 
-%typeselect_no_parens, select_with_parens, select_clause,
+%typeselect_no_parens select_with_parens select_clause
simple_select
 
 %type alter_column_default
 %type drop_behavior
 
-%typecreatedb_opt_list, createdb_opt_item
+%typecreatedb_opt_list createdb_opt_item
 
-%typeopt_lock, lock_type
-%type opt_force, opt_or_replace
+%typeopt_lock lock_type
+%type opt_force opt_or_replace
 
 %typeuser_list
 
@@ -165,7 +165,7 @@
 %typeOptUserList
 %type  OptUserElem
 
-%type TriggerActionTime, TriggerForSpec, opt_trusted, opt_procedural
+%type TriggerActionTime TriggerForSpec opt_trusted opt_procedural
 %type opt_lancompiler
 
 %type OptConstrFromTable
@@ -173,111 +173,111 @@
 %type TriggerEvents
 %type   TriggerFuncArg
 
-%type relation_name, copy_file_name, copy_delimiter, copy_null,
-   database_name, access_method_clause, access_method, attr_name,
-   class, index_name, name, func_name, file_name
+%type relation_name copy_file_name copy_delimiter copy_null
+   database_name access_method_clause access_method attr_name
+   class index_name name func_name file_name
 
-%type opt_id,
-   all_Op, MathOp, opt_name,
-   OptUseOp, opt_class, 

Re: [HACKERS] v7.2.4 bundled ...

[Christopher Kings-Lynne]

All tests pass on FreeBSD/Alpha.

Chris

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Magnus
> Naeslund(f)
> Sent: Thursday, 30 January 2003 2:13 PM
> To: Marc G. Fournier; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] v7.2.4 bundled ... 
> 
> 
> Redhat 6.2
> Linux gserver1 2.4.19-pre6 #4 Thu Apr 11 07:17:39 CEST 2002 alpha
> unknown
> All 79 tests passed.
> 
> Magnus
> 
> 
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [mail] Re: [HACKERS] Windows Build System

[Vince Vielhaber]

On Wed, 29 Jan 2003, Dave Page wrote:

> I would be interested to know how many windows servers those that are
> against a windows port of PostgreSQL have or do manage, and how
> experienced they are with that platform...

At this point I'm not for or against.  But you're going to have to do
more than a weeks worth of unscientific testing to prove your point
and move from assumptions to facts.

Vince.
-- 
 Fast, inexpensive internet service 56k and beyond!  http://www.pop4.net/
   http://www.meanstreamradio.com   http://www.unknown-artists.com
 Internet radio: It's not file sharing, it's just radio.


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [mail] Re: [HACKERS] Windows Build System

[Tom Lane]

"Dave Page" <[EMAIL PROTECTED]> writes:
>> Aside from load testing as suggested by Vince, I'd be 
>> interested to hear what happens when you pull the power cord 
>> under load (repeatedly).  This would give some evidence about 
>> the robustness of the Windows filesystem and its ability to 
>> emulate Unix sync semantics.

> OK, I can maybe do some testing on that next week (I'm off for a few
> days from today). Is there anything in particular I should look out for,
> or that you would want tested?

Make sure your test load includes lots of updating queries, and look for
database corruption --- bad data, duplicated rows, lost rows, that sort
of thing.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [mail] Re: [HACKERS] Windows Build System

[Vince Vielhaber]

On Wed, 29 Jan 2003, Dave Page wrote:

> > The code's been available for what a week or two?  Do you
> > actually think that can be considered conclusive by any standard?
>
> Public beta testing (but closed source) has been going on for some
> months.

So you've been running these unscientific tests you're telling us
about being so successful for "some months"?

Vince.
-- 
 Fast, inexpensive internet service 56k and beyond!  http://www.pop4.net/
   http://www.meanstreamradio.com   http://www.unknown-artists.com
 Internet radio: It's not file sharing, it's just radio.


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [mail] Re: [HACKERS] Windows Build System

[Dave Page]

> -Original Message-
> From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] 
> Sent: 29 January 2003 17:10
> To: Dave Page
> Cc: Katie Ward; Tom Lane; Curtis Faith; [EMAIL PROTECTED]
> Subject: RE: [mail] Re: [HACKERS] Windows Build System
> 
> 
> On Wed, 29 Jan 2003, Dave Page wrote:
> 
> > I would be interested to know how many windows servers 
> those that are 
> > against a windows port of PostgreSQL have or do manage, and how 
> > experienced they are with that platform...
> 
> At this point I'm not for or against.  But you're going to 
> have to do more than a weeks worth of unscientific testing to 
> prove your point and move from assumptions to facts.

No problem with that. Likewise however, it'd be nice if people weren't
against the windows port until testing had proved it didn't work
properly. Would we have the same general reactions to a revived VMS port
or one for OS/2 (not counting Tom's which is an valid concern over a
specific issue)? I suspect not...

Regards, Dave.

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [mail] Re: [HACKERS] Windows Build System

[Dave Page]

> -Original Message-
> From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] 
> Sent: 29 January 2003 17:13
> To: Dave Page
> Cc: Katie Ward; Tom Lane; Curtis Faith; [EMAIL PROTECTED]
> Subject: RE: [mail] Re: [HACKERS] Windows Build System
> 
> 
> On Wed, 29 Jan 2003, Dave Page wrote:
> 
> > > The code's been available for what a week or two?  Do you 
> actually 
> > > think that can be considered conclusive by any standard?
> >
> > Public beta testing (but closed source) has been going on for some 
> > months.
> 
> So you've been running these unscientific tests you're 
> telling us about being so successful for "some months"?

No, I've spent a few days here and there on it, and left things running
for the odd couple of days. I'm certainly not the only tester though.

Regards, Dave.

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [mail] Re: [HACKERS] Windows Build System

[Vince Vielhaber]

On Wed, 29 Jan 2003, Katie Ward wrote:

> > On Wed, 29 Jan 2003, Katie Ward wrote:
> >
> > > > On Wed, 29 Jan 2003, Dave Page wrote:
> > > >
> > > > > > hammering the betas is a far cry from an "industrial-strength
> > > > > > solution".
> > > > >
> > > > > Have you a better suggestion? Seems a bit catch 22 if testing won't
> > > > > prove it's good and we can't use it until we know it's
> > good... Still,
> > > > > industrial strength testing or not, it's more reliable than
> > the SQL 2000
> > > > > and DB2 installations I have here.
> > > >
> > > > Well you have a beta running, load it up with data and let a
> > few hundred
> > > > clients loose on it.  I've seen win2k BSOD with less stress than that.
> > > >
> > > > Vince.
> > >
> > > We did that as part of our internal testing, using the ATM
> > database and a
> > > dual-processor machine.  We tried both with clients connecting and
> > > disconnection quickly, and with large numbers of clients that stayed
> > > connected for a while, all extremely active.  Native Win32 performed
> > > comparably with running the same test on comparable machines on LINUX.
> > > Nothing crashed.
> >
> > The code's been available for what a week or two?  Do you actually
> > think that can be considered conclusive by any standard?
> >
> > Vince.
>
> I am the lead developer on the native windows port.  I have been using and
> testing it for 6 months.  However, what testing is ever conclusive?.  It is
> just evidence that more testing by more people should be done.

Testing to what standards?  IMO the lead developer performing these tests
is even less than scientific.  There are things you will always know that
someone else testing it won't know and they will be more likely to try
something that you wouldn't that may show less than stellar results.
You've tried what's supposed to work, but how much effort have you put in
that's not supposed to work?  Are you that sure that if you were to feed
an oddball query that will simply close the backend on a unix platform
won't send your OS off into the weeds?

Vince.
-- 
 Fast, inexpensive internet service 56k and beyond!  http://www.pop4.net/
   http://www.meanstreamradio.com   http://www.unknown-artists.com
 Internet radio: It's not file sharing, it's just radio.


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [mail] Re: [HACKERS] Windows Build System

[Vince Vielhaber]

On Wed, 29 Jan 2003, Dave Page wrote:

>
>
> > -Original Message-
> > From: Vince Vielhaber [mailto:[EMAIL PROTECTED]]
> > Sent: 29 January 2003 17:10
> > To: Dave Page
> > Cc: Katie Ward; Tom Lane; Curtis Faith; [EMAIL PROTECTED]
> > Subject: RE: [mail] Re: [HACKERS] Windows Build System
> >
> >
> > On Wed, 29 Jan 2003, Dave Page wrote:
> >
> > > I would be interested to know how many windows servers
> > those that are
> > > against a windows port of PostgreSQL have or do manage, and how
> > > experienced they are with that platform...
> >
> > At this point I'm not for or against.  But you're going to
> > have to do more than a weeks worth of unscientific testing to
> > prove your point and move from assumptions to facts.
>
> No problem with that. Likewise however, it'd be nice if people weren't
> against the windows port until testing had proved it didn't work
> properly. Would we have the same general reactions to a revived VMS port
> or one for OS/2 (not counting Tom's which is an valid concern over a
> specific issue)? I suspect not...

VMS and OS/2 have proven track records of being rugged.  Windows has
always had a reputation of being fragile.  And yes, I have extensive
experience with all three.

Vince.
-- 
 Fast, inexpensive internet service 56k and beyond!  http://www.pop4.net/
   http://www.meanstreamradio.com   http://www.unknown-artists.com
 Internet radio: It's not file sharing, it's just radio.


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [mail] Re: [HACKERS] Windows Build System

[Katie Ward]

The latest build is still: ftp://209.61.187.152/postgres/postgres_beta4.zip

This is not exactly what Jan submitted, and the catalog number is slightly
different, but it should do for testing.

Katie


> -Original Message-
> From: Dave Page [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 29, 2003 12:02 PM
> To: Tom Lane
> Cc: Vince Vielhaber; Katie Ward; Curtis Faith;
> [EMAIL PROTECTED]
> Subject: RE: [mail] Re: [HACKERS] Windows Build System
>
> Katie, can I get the latest build from anywhere?
>
> Regards, Dave.


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [mail] Re: [HACKERS] Windows Build System

[James Hubbard]

Vince Vielhaber wrote:

On Wed, 29 Jan 2003, Dave Page wrote:



The code's been available for what a week or two?  Do you
actually think that can be considered conclusive by any standard?


Public beta testing (but closed source) has been going on for some
months.



So you've been running these unscientific tests you're telling us
about being so successful for "some months"?

Vince.


I open my mouth and insert foot:  Where do I get any of these scientific 
tests to determine if the latest and greatest 7.3.x will not fall down on my 
favorite Unix?

James Hubbard


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [mail] Re: [HACKERS] Windows Build System

[Justin Clift]

Katie Ward wrote:

The latest build is still: ftp://209.61.187.152/postgres/postgres_beta4.zip

This is not exactly what Jan submitted, and the catalog number is slightly
different, but it should do for testing.


In case anyone's interested, there are step by step installation 
instructions for it at:

http://techdocs.postgresql.org/guides/InstallingOnWindows

;-)

Regards and best wishes,

Justin Clift


Katie



--
"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 try to be in the
first group; there was less competition there."
- Indira Gandhi


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Testing for int64 (was Re: [COMMITTERS] pgsql-server/ /configure

[Peter Eisentraut]

Tom Lane writes:

> I think a reasonable choice in cross-compiling situations would be to
> assume int64 works if we have a long long int datatype, but to force use
> of our own snprintf rather than trusting to luck with the platform's.

That's approximately what's happening.  Formerly it insisted on doing a
run check to detect the int64 type.  Now it does a compile check when
cross-compiling.

For the snprintf format detection we obviously don't have that chance.  I
just refactored the code a little and added a cache variable so the
advanced cross-compiling user can override the check with known values.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Request for qualified column names

[Peter Eisentraut]

Dave Cramer writes:

> The method in question is
> ResultSetMetaDate.getTableName(int column)
> and while were at it
> ResultSetMetaData.getSchemaName(int column)
> and FWIW, the return value if not applicable is ""

Not applicable sounds fine to me.  It's like taking a file descriptor and
asking what file it belongs to.  That information simply doesn't exist,
and if you design an application around it you lose.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [mail] Re: [HACKERS] Windows Build System

[Justin Clift]

James Hubbard wrote:


I open my mouth and insert foot:  Where do I get any of these scientific 
tests to determine if the latest and greatest 7.3.x will not fall down 
on my favorite Unix?

For Open Source benchmarks, there is:

Open Source Database Benchmark:
http://osdb.sf.net

With this, you *want* to use the latest CVS version, as that can 
generate it's own datasets of any size.  The older, released versions 
couldn't and you had to download databases of limited size.


Database Opensource Test Suite:
http://ltp.sourceforge.net/dotshowto.php

This works with DB2, Oracle, Sybase, MySQL, and PostgreSQL, and looks to 
have been developed by IBM.  Haven't yet used this, but did notice that 
the configuration instructions make no reference to upping the memory 
buffers.  i.e. all of the tests they've done were probably with the 
defaults (yuck!)

Emailed this group yesterday asking if they're open to suggestions for 
improvement, and they said they definitely are.  If anyone has specific 
they'd like to let them know, they do seem open to it.


A commercial solution that people often mention is Benchmark Factory:

http://www.benchmarkfactory.com

Haven't personally used it, although it's apparently the software that 
Great Bridge used for all of their testing.


Hope this helps.

Regards and best wishes,

Justin Clift


James Hubbard



--
"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 try to be in the
first group; there was less competition there."
- Indira Gandhi


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Fix for log_min_error_messages

[Peter Eisentraut]

Bruce Momjian writes:

> I now realize panic isn't really off, but I don't expect panic to happen
> too often.  :-)

Just add a level past panic that actually says "off" and really is off.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] JDBC drivers and streaming content

[Chris Smith]

Actually, I originally sent that message a week ago, and it got posted then
and again now.  Not sure exactly why it was repeated... in any case, the
work I was planning on doing is pretty much done; I want to do some more
testing and refinement to handle performance issues, and I can post a patch.
Then again, if you've already got it done (but, it seems, not released) then
I won't do so.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Fix for log_min_error_messages

[Tom Lane]

Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> I now realize panic isn't really off, but I don't expect panic to happen
>> too often.  :-)

> Just add a level past panic that actually says "off" and really is off.

Would anyone actually use it?  *Should* anyone actually use it?
I cannot imagine a situation where you don't want to see panic messages
(besides, there's always the option of routing the log to /dev/null...)

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Win32 port patches submitted

[Jan Wieck]

Peter Eisentraut wrote:
> 
> Justin Clift writes:
> 
> > The advantages to having the Win32 port be natively compatible with
> > Visual Studio is that it already is (no toolset-porting work needed
> > there),
> 
> You're missing a couple of points here.  First, the MS Visual whatever
> compiler can also be used with a makefile-driven build system.  Second,
> the port as it stands isn't really compatible with anything except Jan's
> build instructions.  There's a lot of work to be done before we get
> anything that builds out of the box in the 7.4 branch, and it's going to
> be a lot easier if we do it using the build system we already have and
> know.

Absolutely right, I know that the build environment is more a mess than
an environment. All I said is that we have a stable, working, native
Win32 PostgreSQL 7.2.1 ... 

And I don't care if we use MingW, Borland, Cygwin or a big blend of it
all, as long as the final result can be shipped binary under the BSD
license. 


Jan

-- 
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.  #
#== [EMAIL PROTECTED] #

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Win32 port patches submitted

[Dann Corbit]

> -Original Message-
> From: Jan Wieck [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, January 29, 2003 11:47 AM
> To: Peter Eisentraut
> Cc: Justin Clift; Hannu Krosing; Bruce Momjian; Tom Lane; 
> Postgres development
> Subject: Re: [HACKERS] Win32 port patches submitted
> 
> 
> Peter Eisentraut wrote:
> > 
> > Justin Clift writes:
> > 
> > > The advantages to having the Win32 port be natively 
> compatible with 
> > > Visual Studio is that it already is (no toolset-porting 
> work needed 
> > > there),
> > 
> > You're missing a couple of points here.  First, the MS 
> Visual whatever 
> > compiler can also be used with a makefile-driven build system.  
> > Second, the port as it stands isn't really compatible with anything 
> > except Jan's build instructions.  There's a lot of work to be done 
> > before we get anything that builds out of the box in the 
> 7.4 branch, 
> > and it's going to be a lot easier if we do it using the 
> build system 
> > we already have and know.
> 
> Absolutely right, I know that the build environment is more a 
> mess than an environment. All I said is that we have a 
> stable, working, native Win32 PostgreSQL 7.2.1 ... 
> 
> And I don't care if we use MingW, Borland, Cygwin or a big 
> blend of it all, as long as the final result can be shipped 
> binary under the BSD license. 

It would be very nice if we could drive the whole thing under Mingw.  It
has an environment that the current developers will be familiar with
(bash, ksh, GCC, etc.) and probably some scripts could perform all the
manual operations.

Is there a place I can download the current patched tree?  I might look
at automating the process to some degree.

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Recursive unions

[Hannu Krosing]

Tom Lane kirjutas K, 29.01.2003 kell 17:58:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > What was the result of the recursive unions thread?  I remember Tom maybe
> > saying that the Redhat guys like the DB2 (SQL99) syntax the best, however
> > was it said that that was going to be done by Redhat for 7.4?
> 
> It'll be looked at; whether it will be done in time for 7.4 is anyone's guess.

Is anyone actually working on it ?

I had some work on it done in this direction for 7.2.x (yacc patches up
to parse tree generation).

If nobody is currently doing it, I would start pushing it by bringing my
work to 7.4 and then doing small amounts of work and then bugging the
list about what would be the best ways to continue, repeating it until
it is done ;)

-- 
Hannu Krosing <[EMAIL PROTECTED]>

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Recursive unions

[Tom Lane]

Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tom Lane kirjutas K, 29.01.2003 kell 17:58:
>> It'll be looked at; whether it will be done in time for 7.4 is anyone's guess.

> Is anyone actually working on it ?

I don't think any significant work has been done yet.  If you wanted to
update your existing patches to CVS tip, that would be helpful I'm sure.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])