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 e
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)---
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).
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
> > 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,
"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
-
> 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 T
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
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
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
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
Unfortun
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
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
fair
> 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.
E
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 implementa
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 n
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 pla
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
restric
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 a
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'"
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
> b
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
--
- 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 straightforwa
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 th
24 matches
Mail list logo
