On trying to recompile things, I find that contrib/intarray is broken
by this change, because it's using the flags field for its own purposes:
/*
* flags for gist__int_ops, use ArrayType-flags
* which is unused (see array.h)
*/
#define LEAFKEY (131)
#define ISLEAFKEY(x)(
Joe Conway [EMAIL PROTECTED] writes:
Jim C. Nasby wrote:
Instead of bending over backwards to try and support older cases, would
a compatability mode be possible? Seems that would solve a lot of
problems.
Last time I thought about this problem, that's what I concluded. I don't
think there
I wrote:
... Now, when the bitmap is present, it would be fairly tedious
to calculate the length of the bitmap to determine the offset to the
actual data; and that's an operation that we'd like to be cheap. What
I'm thinking of doing is commandeering the whole flags field of
ArrayType (which
How about representing null array elements with a special-case cast-like
null? Something like {::null}
__
Marc
On Tue, 2005-11-08 at 23:30 -0400, [EMAIL PROTECTED]
wrote:
Date: Tue, 08 Nov 2005 19:21:34 -0500
From: Tom Lane [EMAIL PROTECTED]
To: pgsql-hackers@postgreSQL.org
Subject: Re:
Marc Munro [EMAIL PROTECTED] writes:
How about representing null array elements with a special-case cast-like
null? Something like {::null}
The problem with *any* proposal for let's-spell-NULL-like-this
is that this is inevitably a string that is valid as a text
data value. Making the string
On Wed, Nov 09, 2005 at 11:22:37AM -0500, Tom Lane wrote:
Marc Munro [EMAIL PROTECTED] writes:
How about representing null array elements with a special-case cast-like
null? Something like {::null}
The problem with *any* proposal for let's-spell-NULL-like-this
is that this is inevitably
Joe Conway wrote:
Last time I thought about this problem, that's what I concluded. I don't
think there is a reasonable and backward compatible solution.
I also think the best non-compatible solution is to require non-numeric
elements to be delimited (double quotes, configurable?), and use
Ron Mayer [EMAIL PROTECTED] writes:
If we're going non-computable, would something that's a superset
of the SQL Standard's array value constructor be useful;
I think you've confused ARRAY[] expressions with the I/O representation
for array values. There are many good reasons why those are not
Hello,
it's great news. My personal opinion about formating NULL values
'{a,,b} -- wrong, means empty string, isn't null
'{a,,b} ' -- ok, maybe not unique,
'{a, NULL, b}' -- longer, clean NULL is NULL
'{a, NULL, b}' -- NULL is not null varchar 'NULL'
Flags for array? Maybe bit
Pavel Stehule [EMAIL PROTECTED] writes:
it's great news. My personal opinion about formating NULL values
'{a, NULL, b}' -- longer, clean NULL is NULL
Unfortunately, that already has a meaning, and it's not that.
regards, tom lane
---(end of
Tom Lane wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
it's great news. My personal opinion about formating NULL values
'{a, NULL, b}' -- longer, clean NULL is NULL
Unfortunately, that already has a meaning, and it's not that.
What a pity. I don't see any alternative to
and so the most straightforward thing to do is define an empty element
as meaning a NULL. But this might be objected to on a couple of
grounds:
Can you use a default to allow the user to specify the default value for
an element? May look a little strange, though, if the user specifies a
In article [EMAIL PROTECTED],
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
it's great news. My personal opinion about formating NULL values
'{a, NULL, b}' -- longer, clean NULL is NULL
Unfortunately, that already has a meaning, and
Pollard, Mike [EMAIL PROTECTED] writes:
Can you use a default to allow the user to specify the default value for
an element?
There's no mechanism for specifying a default value for individual
elements within an array; and I've never heard one asked for. Certainly
it's far less interesting than
and so the most straightforward thing to do is define an empty element
as meaning a NULL. But this might be objected to on a couple of
grounds:
Can you use a default to allow the user to specify the default value for
an element? May look a little strange, though, if the user specifies a
Harald Fuchs [EMAIL PROTECTED] writes:
Tom Lane wrote:
Unfortunately, that already has a meaning, and it's not that.
How about '{a, \N, b}'?
That's valid syntax too, ie, adopting that syntax would break
applications that are not broken today.
Not to mention that it would be gratuitously
I wrote:
... the most straightforward thing to do is define an empty element
as meaning a NULL. But this might be objected to on a couple of grounds:
I just thought of another, potentially fatal objection: it's ambiguous
whether '{}'::text[] should be taken to mean an empty (zero-length)
array
On Tue, Nov 08, 2005 at 07:21:34PM -0500, Tom Lane wrote:
I wrote:
... the most straightforward thing to do is define an empty element
as meaning a NULL. But this might be objected to on a couple of grounds:
I just thought of another, potentially fatal objection: it's ambiguous
whether
On Tue, Nov 08, 2005 at 07:21:34PM -0500, Tom Lane wrote:
I wrote:
... the most straightforward thing to do is define an empty element
as meaning a NULL. But this might be objected to on a couple of grounds:
I just thought of another, potentially fatal objection: it's ambiguous
whether
Jim C. Nasby wrote:
On Tue, Nov 08, 2005 at 07:21:34PM -0500, Tom Lane wrote:
... the most straightforward thing to do is define an empty element
as meaning a NULL. But this might be objected to on a couple of grounds:
I just thought of another, potentially fatal objection: it's ambiguous
I also think the best non-compatible solution is to require non-numeric
elements to be delimited (double quotes, configurable?), and use NULL
unadorned to represent NULL.
I think the ultimate solution should have null values represented by
NULL... I mean NULL is NULL :)
Chris
I'm starting to think about what it'll take to allow arrays to contain
elements that are NULL. The behavioral semantics seem pretty
straightforward, but there are a couple of areas that need discussion.
One trouble spot is what the I/O representation should look like.
Since 8.0, the array input
22 matches
Mail list logo
