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
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 supporting
Pavel Stehule pavel.steh...@gmail.com 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
On Wed, Feb 18, 2009 at 10:30:12AM -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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 pete...@gmx.net 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
Sam Mason s...@samason.me.uk 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
On Thu, Feb 19, 2009 at 02:02:06PM -0500, Tom Lane wrote:
Sam Mason s...@samason.me.uk 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
Pavel Stehule wrote:
2009/2/16 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
Peter Eisentraut pete...@gmx.net 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
2009/2/18 Peter Eisentraut pete...@gmx.net:
Pavel Stehule wrote:
2009/2/16 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
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
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
2009/2/16 Sam Mason s...@samason.me.uk:
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
On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
2009/2/16 Sam Mason s...@samason.me.uk:
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
Pavel Stehule pavel.steh...@gmail.com 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
2009/2/16 Sam Mason s...@samason.me.uk:
On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
2009/2/16 Sam Mason s...@samason.me.uk:
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
On Mon, Feb 16, 2009 at 04:40:23PM +0100, Pavel Stehule wrote:
2009/2/16 Sam Mason s...@samason.me.uk:
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
2009/2/16 Sam Mason s...@samason.me.uk:
On Mon, Feb 16, 2009 at 04:40:23PM +0100, Pavel Stehule wrote:
2009/2/16 Sam Mason s...@samason.me.uk:
On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
so these modules (decode, oraemptystr) decrease differences between
PostgreSQL and
On Mon, Feb 16, 2009 at 08:03:42PM +0100, Pavel Stehule wrote:
2009/2/16 Sam Mason s...@samason.me.uk:
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
2009/2/16 Sam Mason s...@samason.me.uk:
On Mon, Feb 16, 2009 at 08:03:42PM +0100, Pavel Stehule wrote:
2009/2/16 Sam Mason s...@samason.me.uk:
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:
2009/2/16 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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,
Peter Eisentraut wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
2009/2/13 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Peter Eisentraut wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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
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/12 Peter Eisentraut pete...@gmx.net:
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=#
Peter Eisentraut pete...@gmx.net 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
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
Pavel Stehule pavel.steh...@gmail.com 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
2009/2/11 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
Pavel Stehule pavel.steh...@gmail.com writes:
2009/2/11 Tom Lane t...@sss.pgh.pa.us:
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
2009/2/11 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/2/11 Tom Lane t...@sss.pgh.pa.us:
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
33 matches
Mail list logo
