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 (1<<31)
#define ISLEAFKEY(x)( ((Array
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
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
> th
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 n
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 NU
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
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 st
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
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
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
whe
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
> wh
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
> wheth
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)
arra
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 gratuitous
> 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
defa
"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
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 alr
> 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
def
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 t
"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
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 bi
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 p
22 matches
Mail list logo
