Re: [HACKERS] Cursors and backwards scans and SCROLL
Tom Lane kirjutas P, 09.03.2003 kell 22:35: > However, this is going to create backwards-compatibility issues. > We have a few options for what to do: > > 1. Enforce the SQL spec requirement: error out if backwards fetch is > done when SCROLL wasn't given. But this will surely break a lot > of existing applications that work perfectly well. We could start by issuing a NOTICE/WARNING as a step towards the strict compliance and provide a GUC variable for those who are unable to cope even with the warning. The warning could be issued at two places - 1. ( more annoying ) issue it at cursor creation time when a plan is chosen that can't be fetched backwards. 2. like your #2, but just give a warning and then run the underlying query _again_, this toime with materialize on top and also do a Move to reposition the cursor. This will probably not work correctly for all tranasaction isolation levels though but it will penalize only these cases that absolutely need it. The penalty will of course be heavier ;( - Hannu ---(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] SQL99 ARRAY support proposal
Joe Conway kirjutas E, 10.03.2003 kell 05:35: > CREATE OR REPLACE FUNCTION array_push (anyarray, anyscalar) > RETURNS anyarray > AS '$libdir/plr','array_push' > LANGUAGE 'C'; could you make it RETURNS typeof($1) ? -- Hannu ---(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] SQL99 ARRAY support proposal
Joe Conway <[EMAIL PROTECTED]> writes:
> It seems that "any" is not accepted as a function parameter type.
You have to double-quote it.
We could perhaps rename it to avoid the keyword conflict; I'd lean
towards "anytype" if we do ("anyscalar" seems misleading; I'd expect
that to exclude arrays). I think I chose ANY because there was
precedent in CREATE AGGREGATE for that.
> So far, so good. But now the second problem:
> select f1[2] from
> (select array_push('{1,2}'::integer[],3::integer) as f1) as t;
> ERROR: transformArraySubscripts: type anyarray is not an array
Mph. I'm not sure we can make that work readily ... unless you want
to make the parser assume that a function taking and returning ANYARRAY
actually returns the same array type as its input is. Otherwise the
parser has no way to determine the datatype yielded by f1[2].
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] SQL99 ARRAY support proposal
Tom Lane wrote:
I played with generalizing array functions a bit for plr and ran into
some problems (which I can't specifically recall at the moment), but
clearly that's the way to go. I'll start playing with your suggestions
in C code, and report back for more feedback as it solidifies.
It'd be useful if you can reconstruct what problems you ran into.
I've played around a bit more and refreshed my memory -- here are two
problems:
CREATE OR REPLACE FUNCTION array_push (anyarray, any)
RETURNS anyarray
AS '$libdir/plr','array_push'
LANGUAGE 'C';
ERROR: parser: parse error at or near "any" at character 50
It seems that "any" is not accepted as a function parameter type. From
gram.y it appears that the cause is that "any" is a reserved keyword:
/*
* Name classification hierarchy.
*
* IDENT is the lexeme returned by the lexer for identifiers that match
* no known keyword. In most cases, we can accept certain keywords as
/* Type identifier --- names that can be type names.
*/
type_name: IDENT { $$ = $1; }
| unreserved_keyword { $$ = pstrdup($1); }
;
So for grins I did this:
regression=# select oid,typname from pg_type where typname like '%any%';
oid | typname
--+--
2276 | any
2277 | anyarray
(2 rows)
regression=# update pg_type set typname = 'anyscalar' where oid = 2276;
UPDATE 1
CREATE OR REPLACE FUNCTION array_push (anyarray, anyscalar)
RETURNS anyarray
AS '$libdir/plr','array_push'
LANGUAGE 'C';
regression=# select array_push('{1,2}'::integer[],3::integer);
array_push
{1,2,3}
(1 row)
So far, so good. But now the second problem:
select f1[2] from
(select array_push('{1,2}'::integer[],3::integer) as f1) as t;
ERROR: transformArraySubscripts: type anyarray is not an array
I'm just starting to dig into this one.
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Cursors and backwards scans and SCROLL
> > I'd be in favour of creating whole sets of backwards-compatibility GUC's > > whenever we break backwards compatibility. > > > > eg. > > use_72_compat = yes > > use_73_compat = yes > > That sounds like a recipe for a maintenance nightmare to me. We only have to keep them for one major version, say. eg. 7.3 release would remove the 71_compat option... Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Cursors and backwards scans and SCROLL
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > I'd be in favour of creating whole sets of backwards-compatibility GUC's > whenever we break backwards compatibility. > > eg. > use_72_compat = yes > use_73_compat = yes That sounds like a recipe for a maintenance nightmare to me. -Doug ---(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] Cursors and backwards scans and SCROLL
> 3. Create a runtime parameter (GUC variable) which when set causes us > to assume SCROLL is present even if it's not stated. Setting this > to TRUE would allow existing applications to work without modification; > when it's FALSE, we'd enforce the spec behavior. The trouble with this > is the TRUE setting would likely cause materialization costs to be paid > in very many situations where the client has no intention of fetching > backwards. I'd be in favour of creating whole sets of backwards-compatibility GUC's whenever we break backwards compatibility. eg. use_72_compat = yes use_73_compat = yes or something. And then we can define all the things that those variables will affect. That would mean that people can upgrade to new db engine (say 7.3) without worrying about all the failures in their applications ( eg ''::int)... Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Who puts the Windows binaries on the FTP server?
Justin Clift writes: > > I thought the idea was initdb would be rewritten in C. We cannot include > > grep/sed etc as they're GPL... > > I heard Peter mention that, but my email seems to be a tad spotty and I > haven't come across the rest of the conversation about it. I've started rewriting some of the shell scripts in C. initdb will be a lot trickier. We'll see. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] test news gateway ...
---(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] [GENERAL] division by zero
Hi guys, Was just looking around Google for similar reports of errors and came across this: MacOS X Server Developer Release Notes: Core OS Runtime http://www.geminisolutions.com/WebObjects_4.5/Documentation/Developer/YellowBox/ReleaseNotes/Runtime.html Looks like this is a known problem (as of 1998) and may not have been fixed. Further hits come up when searching on the Apple Developer Connection site too: http://developer.apple.com/cgi-bin/search.pl?&q=divide+by+zero&num=10&lang=lang_en|lang_zh-CN|lang_fr|lang_de|lang_ja&ie=utf8&oe=utf8 (that should be all one line) And this one looks potentially interesting: http://developer.apple.com/technotes/tn2002/tn2053.html (search in this page for "FE_ENABLE_DIVBYZERO") Have asked the member of the Apple MacOS X Server team what he recommends the best way to proceed is. Regards and best wishes, Justin Clift Eric B.Ridge wrote: On Saturday, March 8, 2003, at 11:54 PM, Justin Clift wrote: Tom Lane wrote: 2. Consider this Apple's problem and file a bug report. Is there a good place to report errors to Apple for this kind of thing? The best place I can find is: http://developer.apple.com/bugreporter/index.html Unfortunately, there doesn't seem to be a way to query existing reports... If there is, I can't find it. Also, I can't help but wonder why Apple/DarwinTeam handle integer division by zero this way. There must be a reason, which makes me think that "[considering] this Apple's problem" might not work out for postgres in the end. eric -- "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 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] division by zero
On Saturday, March 8, 2003, at 11:54 PM, Justin Clift wrote: Tom Lane wrote: 2. Consider this Apple's problem and file a bug report. Is there a good place to report errors to Apple for this kind of thing? The best place I can find is: http://developer.apple.com/bugreporter/index.html Unfortunately, there doesn't seem to be a way to query existing reports... If there is, I can't find it. Also, I can't help but wonder why Apple/DarwinTeam handle integer division by zero this way. There must be a reason, which makes me think that "[considering] this Apple's problem" might not work out for postgres in the end. eric ---(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] Cursors and backwards scans and SCROLL
On Sun, 2003-03-09 at 16:04, Rod Taylor wrote: > How about a variable that turns on or off spec enforcement (case #1 or > #2). On for 7.4, off for 7.5 the next release, and make it disappear > after that. Yeah, that sounds like the best solution to me. IMHO there is a case to be made for skipping straight to defaulting to 'on' in 7.4, and removing the GUC var in 7.5 Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(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] Cursors and backwards scans and SCROLL
Rod Taylor <[EMAIL PROTECTED]> writes: > Enforcing spec seems like the least confusing mode to operate under, > especially given it could break simply by changing the plan -- which > happens automagically (seemingly random). Keep in mind though that complaints about the current bugs have been fairly infrequent, which means that most people either don't try to fetch backwards from a cursor, or don't try to do so on complex plans. I'm hesitant to penalize a larger group for the benefit of a smaller one --- which is why enforcing the spec strictly doesn't really appeal to me, even though one could argue that the larger group had it coming. I'd prefer to be permissive about the cases that we can support at no cost, which not-by-coincidence are the cases that have worked correctly up to now. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Cursors and backwards scans and SCROLL
> I'm presently leaning to #2, even though it exposes implementation > details. I'm open to discussion though. Any preferences? Other ideas? How about a variable that turns on or off spec enforcement (case #1 or #2). On for 7.4, off for 7.5 the next release, and make it disappear after that. Enforcing spec seems like the least confusing mode to operate under, especially given it could break simply by changing the plan -- which happens automagically (seemingly random). -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] [SQL] Cursors and backwards scans and SCROLL
Tom, > Postgres' implementation of cursors has always had a problem with doing > MOVE or FETCH backwards on complex queries. Coincidnetally enough, I was just chatting with one of my contractors yesterday about how the one thing that Transact-SQL has to offer is a really good cursor implementation. It would be lovely to improve ours to match. > Fixing this directly seems unreasonably difficult, so I'm currently > working on fixing it by inserting a Materialize plan node at the top of > the plan tree for a cursor, if the plan tree couldn't otherwise support > backwards scan. The Materialize node will save aside a copy of each row > as it's fetched from the underlying plan, and use this copied table if > any backwards scanning is asked for. Sounds good to me. It's also very similar to what T-SQL does for a STATIC or KEYSET cursor, and works very well in their implementation. (FWIW, T-SQL's cursor types, such as DYNAMIC and KEYSET, are unnecessary for Postgres due to MVCC) > 2. Error out only if a backwards fetch is actually attempted on a plan > tree that can't handle it (which could only happen if SCROLL wasn't > I'm presently leaning to #2, even though it exposes implementation > details. I'm open to discussion though. Any preferences? Other ideas? This sounds like a good idea to me in a staggered-implementation sense if it's doable. That is, we'd implement the behavior in #2 in the next version of Postgresql, and the behavior in #1 or in #3 in the version after that.If, however, the implementation of #2 is too difficult, then I think #3 would be a good choice. >From my perspective, the "SCROLL" declaration has *always* been the SQL-spec, and it is the behaviour used by other databases, even if it's been superflous in PostgreSQL until now. So from that point of view, developers who have been not using "SCROLL" have been sloppy and can reasonably expect to have to audit their code in future versions of PostgreSQL. On the other hand, I don't use cursors much in Postgres, so I'm kind of a priest doing marriage counselling as far as that's concerned. PL/pgSQL's "FOR record IN query" is currently both easier and faster than cursors so I use that 90% of the time. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SQL99 ARRAY support proposal
Joe Conway <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> It would take some hackery to propagate the destination type down into >> the ARRAY[] before the latter's type resolution is done, but at least >> it'd be a quite localized hack. > OK -- I'll try to make that work. I presume that in the non-specified > case "ARRAY[1,2,3]" I should use something similar to UNION's resolution > rules? Yeah, that'd make sense to me. >>> [...lots of good ideas regarding generalizing array operations...] > I played with generalizing array functions a bit for plr and ran into > some problems (which I can't specifically recall at the moment), but > clearly that's the way to go. I'll start playing with your suggestions > in C code, and report back for more feedback as it solidifies. It'd be useful if you can reconstruct what problems you ran into. After more thought I'm thinking that we should specify these pseudotypes like so: a given set of actual operand types matches an operator/function whose definition uses ANYARRAY or ANYELEMENT only if the same element type is involved at all positions. Thus in ANYARRAY = ANYARRAY the left and right operands must be the same array type (so we preserve the existing parse-time check, but we only need one pg_operator entry to do it). For ANYARRAY || ANYELEMENT we get the desired behavior. And there are some other interesting possibilities: for example, a function could be declared foo(ANY, ANYELEMENT, ANYELEMENT) which would mean that it takes any three datatypes, but the second and third arguments have to be the same datatype. If we run into limitations of this scheme, it could be generalized further by adding pseudotypes ANYARRAY2 and ANYELEMENT2 that have the same restriction among themselves, but are independent of ANYARRAY/ANYELEMENT. Then for example foo(ANYELEMENT, ANYELEMENT, ANYELEMENT2, ANYELEMENT2) takes four params that can be anything so long as the first two are the same datatype and the second two are also the same datatype (but possibly a different type from the first two). And you could add ANYARRAY3, etc, till you got bored. But I'd not bother with this until someone showed a concrete need for it. At the moment, the useful examples I can think of don't need more than one "free variable" in their set of argument datatypes. 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
[HACKERS] Cursors and backwards scans and SCROLL
Postgres' implementation of cursors has always had a problem with doing MOVE or FETCH backwards on complex queries. It works okay for simple seqscans and indexscans, but fails for plans involving joins, aggregates, and probably other cases. This happens because the executor routines for those plan types don't cope with being asked to scan backwards. Fixing this directly seems unreasonably difficult, so I'm currently working on fixing it by inserting a Materialize plan node at the top of the plan tree for a cursor, if the plan tree couldn't otherwise support backwards scan. The Materialize node will save aside a copy of each row as it's fetched from the underlying plan, and use this copied table if any backwards scanning is asked for. Of course, copying the data is a waste of cycles if the client never actually asks to scan backwards --- and it could even lead to failures, i.e. running out of disk space. So I think there needs to be a way to control whether Materialize gets added or not. The SQL spec has a provision for this: according to the spec, the client is supposed to say DECLARE foo SCROLL CURSOR FOR ... if he intends to do anything except sequential fetches from the cursor. Postgres presently allows the SCROLL keyword but ignores it. I'd like to set things up so that Materialize is added only when SCROLL appears (and the query plan can't handle backwards scan without it). However, this is going to create backwards-compatibility issues. We have a few options for what to do: 1. Enforce the SQL spec requirement: error out if backwards fetch is done when SCROLL wasn't given. But this will surely break a lot of existing applications that work perfectly well. 2. Error out only if a backwards fetch is actually attempted on a plan tree that can't handle it (which could only happen if SCROLL wasn't given). This is efficient and flexible, but it exposes implementation details to the user, in that whether an error occurs will depend on which plan the system happens to choose. There are cases where identical cursor definitions might allow or not allow backwards fetch depending on the planner's choices. Notice though that errors could occur only in cases that would silently fail in the present code; so existing applications that work reliably would not see such errors. 3. Create a runtime parameter (GUC variable) which when set causes us to assume SCROLL is present even if it's not stated. Setting this to TRUE would allow existing applications to work without modification; when it's FALSE, we'd enforce the spec behavior. The trouble with this is the TRUE setting would likely cause materialization costs to be paid in very many situations where the client has no intention of fetching backwards. I'm presently leaning to #2, even though it exposes implementation details. I'm open to discussion though. Any preferences? Other ideas? 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] SQL99 ARRAY support proposal
Tom Lane wrote: By analogy to the "type 'literal'" syntax? I'd prefer not to go that route, because that syntax for literals is a horrid kluge --- to keep bison from spitting up, we've had to put a bunch of nasty restrictions on the type names that can appear in such constructs. All those restrictions would have to apply here, too. It's possible that we could use the other cast syntaxes: ARRAY[1,2,3]::integer[] CAST(ARRAY[1,2,3] AS integer[]) It would take some hackery to propagate the destination type down into the ARRAY[] before the latter's type resolution is done, but at least it'd be a quite localized hack. OK -- I'll try to make that work. I presume that in the non-specified case "ARRAY[1,2,3]" I should use something similar to UNION's resolution rules? ::= ARRAY ::= ARRAY [ ] This I could live with --- note the difference in punctuation. There would be a clear syntactic and semantic difference between ARRAY(SELECT ...) and ARRAY[(SELECT ...)]. Sorry -- I guess I mis-read that. So "ARRAY(SELECT ...)" it is. > [...lots of good ideas regarding generalizing array operations...] I played with generalizing array functions a bit for plr and ran into some problems (which I can't specifically recall at the moment), but clearly that's the way to go. I'll start playing with your suggestions in C code, and report back for more feedback as it solidifies. Thanks! Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] DECLARE CURSOR to become utility statement
I'm about to change the parsetree representation of DECLARE CURSOR to look more like a standard utility statement: a DeclareCursorStmt node with a SELECT querytree dangling from it. This will make it possible to remove the cursor-specific elements of Query nodes (isPortal, isBinary), rather than adding more as we'd ultimately need to do if we want to have SCROLL, INSENSITIVE, etc do anything. Any objections? 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] SQL99 ARRAY support proposal
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The array type is determined how? I'd like this syntax better if there
>> were a way to force the choice of array type...
> What about:
> select integer ARRAY[1,2,3];
> result '{1,2,3}'::integer[]
By analogy to the "type 'literal'" syntax? I'd prefer not to go that
route, because that syntax for literals is a horrid kluge --- to keep
bison from spitting up, we've had to put a bunch of nasty restrictions
on the type names that can appear in such constructs. All those
restrictions would have to apply here, too.
It's possible that we could use the other cast syntaxes:
ARRAY[1,2,3]::integer[]
CAST(ARRAY[1,2,3] AS integer[])
It would take some hackery to propagate the destination type down into
the ARRAY[] before the latter's type resolution is done, but at least
it'd be a quite localized hack.
>> Puh-leez tell me that's not in the spec. How is one supposed to
>> distinguish this usage from the scalar-subselect case?
> but SQL200x has this:
> ::=
> |
>
> ::=
>ARRAY
>
>
> ::=
>ARRAY
> [ ]
>
This I could live with --- note the difference in punctuation. There
would be a clear syntactic and semantic difference between
ARRAY(SELECT ...) and ARRAY[(SELECT ...)].
>> How many variants of the || operator do you plan to offer?
> One for each builtin datatype[]/datatype pair (e.g. integer[]/integer),
> and another for each datatype[] (e.g. integer[]/integer[])
That does not seem workable at all. It'll be a maintenance nightmare
even worse than what we already have for array equality; and I suspect
you'll find that the parser will have trouble resolving which || to pick.
I have been toying with the idea of replacing all the array-equality
operators with a single pg_proc/pg_operator entry for "ANYARRAY = ANYARRAY".
Now that arrays carry their element type in the header, a single
function could implement all these variants. Type mismatch (eg,
int[] = float[]) would become a runtime error instead of a parse error,
but that seems acceptable.
I see how the array || array cases could be handled similarly, but I
don't see how to make array || scalar work that way. If we declared an
operator ANYARRAY || ANY then there'd be no way for it to check at
runtime that the right-hand operand matched the lefthand element type.
(Also, it'd create resolution conflicts with ANYARRAY || ANYARRAY.)
It'd be nice to have a general-purpose solution for this problem.
If we did, the stuff in contrib/array would benefit too, and perhaps
have (at last) a shot at becoming mainstream.
Speculating wildly: what if we invent a new pseudotype ANYARRAYELEMENT,
which would be allowed only in operator/function declarations that also
use ANYARRAY, eg
ANYARRAY || ANYARRAYELEMENT
and would match only the element type of the array in the ANYARRAY
position. I think it'd be possible to hack the parser to make such a
check in parse_coerce. There might be a cleaner way to do this, but
I do feel that something along this line is a better approach than
creating N different pg_operator entries for the same operation.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] regression failure in CVS HEAD
Neil Conway <[EMAIL PROTECTED]> writes: > On Sat, 2003-03-08 at 21:29, Tom Lane wrote: >> Do you use --enable-depend when configuring? I don't, so I know that >> I take some risk of build errors when I do things wrong. > Yeah, I did -- which I why when I reported it initially I assumed that a > build problem wasn't the cause. Hm. One of the reasons I don't use --enable-depend is that I don't trust it ;-) --- I prefer to do a make clean and rebuild after every cvs update. It's disturbing that we both saw similar failures, when there's no obvious explanation for a build problem in the CVS logs. I have a sneaking feeling that we haven't seen the last of this issue. But with no ability to reproduce it, there's not much point in worrying now. 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] regression failure in CVS HEAD
On Sat, 2003-03-08 at 21:29, Tom Lane wrote: > Do you use --enable-depend when configuring? I don't, so I know that > I take some risk of build errors when I do things wrong. Yeah, I did -- which I why when I reported it initially I assumed that a build problem wasn't the cause. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Who puts the Windows binaries on the FTP server?
- Original Message - From: "Dave Page" <[EMAIL PROTECTED]> > I thought the idea was initdb would be rewritten in C. We cannot include > grep/sed etc as they're GPL... I'd be happy to do this if it hasn't been done. After a quick perusal of the script I think it would be very straightforward. cheers andrew ---(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] Who puts the Windows binaries on the FTP server?
Dave Page wrote: It's rumoured that Justin Clift once said: There's more to making PostgreSQL work on Windows than just the "pure packaging" issues. We still have to figure out how we're going to handle stuff like needed grep, sed, etc just for PostgreSQL to run (they're required by initdb). I thought the idea was initdb would be rewritten in C. We cannot include grep/sed etc as they're GPL... I heard Peter mention that, but my email seems to be a tad spotty and I haven't come across the rest of the conversation about it. That would be really good of course, as it reduces the external dependencies. :) We're also going to need to have a good idea of what other nice features could/should be packaged along with it. i.e.: + a GUI to control some things (installation/deinstallation of the PostgreSQL Service, perhaps vacuuming, etc). Hang on, I heard of a good one the other day... :-) There's a couple of potentials. ;-) + Shortcuts in the Program menu to things (PostgreSQL website(s), online documentation, etc) Those are just decisions to make aren't they? They don't require a Cygwin proof of concept. Sure. But I hadn't thought about them until building the cygwin proof of concept. Think of it as a "test run" to see what kind of things it brought to mind. :) Another thing is the international support. The Proof of Concept version was a bad hack in that it forced installation into "C:\Program Files\PostgreSQL". For non-english versions of Windows, they have "C:\Program Files" being names to other things, dependant on the language. This broke the installation of course. :( With a proper installer (as you've mentioned), that shouldn't be a problem as it should automatically install into the correct "PostgreSQL" subdirectory of whatever the equivalent of "Program Files" is, on whatever drive. Registry entries (if used) should properly match of course. + Which parts of the installation should be mandatory, and which should be optional. i.e. Base server files should be mandatory, HTML docs should be optional, perhaps include the ODBC driver as optional too. Likewise, these are decisions to make and then suitable programming of the installer. Making bits optional should be trivial in any good installer. Don't get me wrong, I think it's great that someone has finally built a good Cygwin based package - I just don't think it answers many of the issues that we will likely encounter. No, but it brought some of them to light. :) Regards, Dave. PS. Is the source on the ftpsite - if not you'll have Jason after you before long :-) The source? It's the standard version of cygwin. It's just packaged differently. :) The packaging scripts themselves though have gone into the ether forever, as the drive they were on was lost a few weeks ago (rebooted one day and it didn't come back). :( If absolutely needed, we could reverse engineer them back from the installation package. (painful) 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 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
