Pavel Stehule writes:
>> Curiously enough, Oracle has it so that || of null arguments treats the
>> arguments as empty string.
>>
>> It's beyond comprehension.
>>
> what is result of '' || '' ?
Well the result of this is NULL of course (which is the same as '')
What's more puzzling is what the
> Curiously enough, Oracle has it so that || of null arguments treats the
> arguments as empty string.
>
> It's beyond comprehension.
>
what is result of '' || '' ?
Pavel
> But yeah, a varchar2 type with a full set of functions and operators could
> work. If you choose not to bother with support
Tom Lane wrote:
How about introducing a "varchar2" type as in Oracle?
Maybe. I think right now we don't allow input functions to decide
that a non-null input string should be converted to a NULL, but
that might be fixable. It'd still be an ugly mess though, since
I suspect you'd have to intro
On Thu, Feb 19, 2009 at 02:02:06PM -0500, Tom Lane wrote:
> Sam Mason writes:
> > On Wed, Feb 18, 2009 at 10:30:12AM -0500, Tom Lane wrote:
> >> AFAIK, the Oracle behavior is just about entirely unrelated to the
> >> parser --- it's a matter of runtime comparison behavior. It is
> >> certainly *n
Sam Mason writes:
> On Wed, Feb 18, 2009 at 10:30:12AM -0500, Tom Lane wrote:
>> AFAIK, the Oracle behavior is just about entirely unrelated to the
>> parser --- it's a matter of runtime comparison behavior. It is
>> certainly *not* restricted to literal NULL/'' constants, which is the
>> only ca
On Thu, Feb 19, 2009 at 06:29:25PM +, Sam Mason wrote:
> On Wed, Feb 18, 2009 at 10:30:12AM -0500, Tom Lane wrote:
> > Peter Eisentraut writes:
> > > I'd be quite interested to support some kind of hook to deal with this
> > > Oracle null issue. It would be a great help for porting projects.
On Wed, Feb 18, 2009 at 10:30:12AM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > I'd be quite interested to support some kind of hook to deal with this
> > Oracle null issue. It would be a great help for porting projects.
>
> > However, doing this properly is probably more complex and n
2009/2/18 Peter Eisentraut :
> Pavel Stehule wrote:
>>
>> 2009/2/16 Tom Lane :
>>>
>>> Pavel Stehule writes:
Next sample of parser hook using:
attachment contains module that transform every empty string to null.
I am not sure, if this behave is exactly compatible with Oracle,
Peter Eisentraut writes:
> I'd be quite interested to support some kind of hook to deal with this
> Oracle null issue. It would be a great help for porting projects.
> However, doing this properly is probably more complex and needs further
> thought. I'd suggest writing a type of regression t
Pavel Stehule wrote:
2009/2/16 Tom Lane :
Pavel Stehule writes:
Next sample of parser hook using:
attachment contains module that transform every empty string to null.
I am not sure, if this behave is exactly compatible with Oracle,
Surely a parser hook like this would have nothing whatsoever
2009/2/16 Tom Lane :
> Pavel Stehule writes:
>> Next sample of parser hook using:
>> attachment contains module that transform every empty string to null.
>> I am not sure, if this behave is exactly compatible with Oracle,
>
> Surely a parser hook like this would have nothing whatsoever to do
> wi
2009/2/16 Sam Mason :
> On Mon, Feb 16, 2009 at 08:03:42PM +0100, Pavel Stehule wrote:
>> 2009/2/16 Sam Mason :
>> > But to do it properly inside PG would be difficult; how would your hooks
>> > know to transform:
>> >
>> > SELECT s FROM foo WHERE s IS NULL;
>> >
>> > into:
>> >
>> > SELECT s FRO
On Mon, Feb 16, 2009 at 08:03:42PM +0100, Pavel Stehule wrote:
> 2009/2/16 Sam Mason :
> > But to do it properly inside PG would be difficult; how would your hooks
> > know to transform:
> >
> > SELECT s FROM foo WHERE s IS NULL;
> >
> > into:
> >
> > SELECT s FROM foo WHERE (s = '' OR s IS NULL)
2009/2/16 Sam Mason :
> On Mon, Feb 16, 2009 at 04:40:23PM +0100, Pavel Stehule wrote:
>> 2009/2/16 Sam Mason :
>> > On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
>> >> so these modules (decode, oraemptystr) decrease differences between
>> >> PostgreSQL and Oracle.
>> >
>> > wouldn
On Mon, Feb 16, 2009 at 04:40:23PM +0100, Pavel Stehule wrote:
> 2009/2/16 Sam Mason :
> > On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
> >> so these modules (decode, oraemptystr) decrease differences between
> >> PostgreSQL and Oracle.
> >
> > wouldn't it be better/easier to exte
2009/2/16 Sam Mason :
> On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
>> 2009/2/16 Sam Mason :
>> > On Mon, Feb 16, 2009 at 02:35:54PM +0100, Pavel Stehule wrote:
>> >> attachment contains module that transform every empty string to null.
>> >
>> > Why would anyone ever want to do
Pavel Stehule writes:
> Next sample of parser hook using:
> attachment contains module that transform every empty string to null.
> I am not sure, if this behave is exactly compatible with Oracle,
Surely a parser hook like this would have nothing whatsoever to do
with Oracle's behavior.
On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
> 2009/2/16 Sam Mason :
> > On Mon, Feb 16, 2009 at 02:35:54PM +0100, Pavel Stehule wrote:
> >> attachment contains module that transform every empty string to null.
> >
> > Why would anyone ever want to do this? This would appear to b
2009/2/16 Sam Mason :
> On Mon, Feb 16, 2009 at 02:35:54PM +0100, Pavel Stehule wrote:
>> attachment contains module that transform every empty string to null.
>
> Why would anyone ever want to do this? This would appear to break all
> sorts of things in very non-obvious ways:
I agree, so this be
On Mon, Feb 16, 2009 at 02:35:54PM +0100, Pavel Stehule wrote:
> attachment contains module that transform every empty string to null.
Why would anyone ever want to do this? This would appear to break all
sorts of things in very non-obvious ways:
SELECT CASE s WHEN '' THEN 'empty string' ELSE
Next sample of parser hook using:
attachment contains module that transform every empty string to null.
I am not sure, if this behave is exactly compatible with Oracle, but
for first iteration it is good.
postgres=# select length('') is null;
?column?
--
t
(1 row)
I thing, so this shou
Heikki Linnakangas wrote:
And on top of that, decode() is supposed to do short-circuit evaluation
of the arguments.
Then the only solution is to hack it right into the parser.
There is an existing decode() function however ...
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
2009/2/13 Heikki Linnakangas :
> Peter Eisentraut wrote:
>>
>> Tom Lane wrote:
>>>
>>> Peter Eisentraut writes:
I think what you want here is some way to define a function that takes
an arbitrary number of arguments of arbitrary type and let the function
figure everything out.
Peter Eisentraut wrote:
Tom Lane wrote:
Peter Eisentraut writes:
I think what you want here is some way to define a function that
takes an arbitrary number of arguments of arbitrary type and let the
function figure everything out. I see no reason why this can't be a
variant on CREATE FUNCTI
Tom Lane wrote:
Peter Eisentraut writes:
I think what you want here is some way to define a function that takes an
arbitrary number of arguments of arbitrary type and let the function figure
everything out. I see no reason why this can't be a variant on CREATE
FUNCTION, except that of course
Peter Eisentraut writes:
> I think what you want here is some way to define a function that takes an
> arbitrary number of arguments of arbitrary type and let the function figure
> everything out. I see no reason why this can't be a variant on CREATE
> FUNCTION, except that of course you need
2009/2/12 Peter Eisentraut :
> On Wednesday 11 February 2009 12:05:03 Pavel Stehule wrote:
>> It works. And I thing, this should to solve lot of special task
>> related to increase compatibility with Oracle, Informix, or it could
>> be usefull for some others (json support).
>>
>> postgres=# load '
On Wednesday 11 February 2009 12:05:03 Pavel Stehule wrote:
> It works. And I thing, this should to solve lot of special task
> related to increase compatibility with Oracle, Informix, or it could
> be usefull for some others (json support).
>
> postgres=# load 'decode';
> LOAD
> postgres=# select
2009/2/11 Tom Lane :
> Pavel Stehule writes:
>> 2009/2/11 Tom Lane :
>>> This strikes me as next door to useless, because it can only handle
>>> things that look like valid expressions to the existing grammar.
>>> So pretty much all you can do is weird sorts of functions, which are
>>> already acc
Pavel Stehule writes:
> 2009/2/11 Tom Lane :
>> This strikes me as next door to useless, because it can only handle
>> things that look like valid expressions to the existing grammar.
>> So pretty much all you can do is weird sorts of functions, which are
>> already accommodated at less effort wit
2009/2/11 Tom Lane :
> Pavel Stehule writes:
>> some years ago there was some plans about parser's extensibility. I am
>> able write bison extensions, but I thing, so lot of work should be
>> done via hooking of transform stage.
>
> This strikes me as next door to useless, because it can only hand
Pavel Stehule writes:
> some years ago there was some plans about parser's extensibility. I am
> able write bison extensions, but I thing, so lot of work should be
> done via hooking of transform stage.
This strikes me as next door to useless, because it can only handle
things that look like vali
Hello
some years ago there was some plans about parser's extensibility. I am
able write bison extensions, but I thing, so lot of work should be
done via hooking of transform stage.
I did small example - real implementation of Oracle's decode function.
It's based on hooking transformExpr function.
33 matches
Mail list logo
