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
- 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.
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] 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
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'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
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
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
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
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
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
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
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
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
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
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
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
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
On Saturday, March 8, 2003, at 11:54 PM, Justin Clift wrote:
Tom Lane wrote:
snip
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
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
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
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.
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
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
24 matches
Mail list logo
