Sam Mason s...@samason.me.uk writes:
Would something like the included patch be accepted?
[ patch to make charin() throw error for excess input ]
I remembered the reason why this idea got rejected previously.
The winning argument was that char should behave as nearly
as possible like the
On Fri, Sep 4, 2009 at 11:15 AM, Tom Lanet...@sss.pgh.pa.us wrote:
I certainly don't want to have char emulate the misbegotten decision
to have explicit and implicit coercions behave differently. So it
looks to me like the argument to make char work like char(1) doesn't
actually help us much
Tom Lane t...@sss.pgh.pa.us wrote:
I certainly don't want to have char emulate the misbegotten
decision to have explicit and implicit coercions behave differently.
So it looks to me like the argument to make char work like char(1)
doesn't actually help us much to decide if an error should
On Fri, Sep 4, 2009 at 11:59 AM, Kevin
Grittnerkevin.gritt...@wicourts.gov wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
I certainly don't want to have char emulate the misbegotten
decision to have explicit and implicit coercions behave differently.
So it looks to me like the argument to make
On Fri, Sep 04, 2009 at 10:59:48AM -0500, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
I certainly don't want to have char emulate the misbegotten
decision to have explicit and implicit coercions behave differently.
So it looks to me like the argument to make char work like
On Fri, 2009-09-04 at 11:15 -0400, Tom Lane wrote:
On the whole, throwing an error seems better from a usability
perspective.
Comments?
Agreed.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
On Fri, Sep 04, 2009 at 12:26:19PM -0500, Kevin Grittner wrote:
Sam Mason s...@samason.me.uk wrote:
Kevin Grittner wrote:
test=# select case when true then 'xxx' else 'a'::char end from t;
'xxx' is being used to initialize a value of char type.
As I read the semantics of the CASE
Sam Mason s...@samason.me.uk wrote:
you seem to be wanting in-memory representations of string like
types to all use the same representation and only use the actual
types when saving to/from disk.
Doing so when actually assigning to *something* of the more specific
type would probably be
Sam Mason s...@samason.me.uk wrote:
I fail to see how an error isn't the right thing; if we try with
some other types let see if you think any of these should succeed.
SELECT CASE WHEN TRUE THEN text 'xxx' ELSE 0 END;
SELECT CASE WHEN TRUE THEN text 'xxx' ELSE TRUE END;
SELECT CASE
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Only, I guess, because of the name. If it weren't called char I
guess I wouldn't be concerned about people expecting it to behave
something like char. If char behaved more like char, the 'xxx'
literal wouldn't be taken as input to the type
Tom Lane t...@sss.pgh.pa.us wrote:
I'm not certain what you're trying to say, but the above is complete
nonsense ...
Ah, so it is. I thought someone up-thread said that in this case it
wound up as bpchar; but I see that's not so:
test=# select pg_typeof((select case when true then 'xxx'
On Fri, Sep 04, 2009 at 02:01:07PM -0500, Kevin Grittner wrote:
char is no different other than, by default, it happens to look a
lot like any value of text type.
So much so that it has the same name as a text type (wrapped in
quotes) and behaves a lot like one:
You're getting bitten by
On Tue, Sep 01, 2009 at 05:49:25PM +0100, Sam Mason wrote:
PG could maybe throw an error to tell you this is
what is happening?
Would something like the included patch be accepted?
--
Sam http://samason.me.uk/
*** src/backend/utils/adt/char.c~ 2009-01-01 17:23:49.0 +
---
Sam Mason s...@samason.me.uk writes:
On Tue, Sep 01, 2009 at 05:49:25PM +0100, Sam Mason wrote:
PG could maybe throw an error to tell you this is
what is happening?
Would something like the included patch be accepted?
ISTM this was debated once before and rejected. However, there's a
The following bug has been logged online:
Bug reference: 5028
Logged by: Joseph Shraibman
Email address: j...@selectacast.net
PostgreSQL version: 8.3.7
Operating system: Linux
Description:CASE returns ELSE value always when type is char
Details:
[local]:playpen=
On Tue, Sep 01, 2009 at 04:36:25PM +, Joseph Shraibman wrote:
Description:CASE returns ELSE value always when type is char
I think it's just silently truncating the literal to a single character.
[local]:playpen= select c.relkind, CASE c.relkind WHEN 'r' THEN 'table'
WHEN 'v' THEN
It appears the problem is with the char being in the ELSE expression,
not being in the CASE expression
[local]:playpen= select c.relkind, CASE c.relkind WHEN 'r' THEN 'table'
WHEN 'v' THEN 'view' WHEN 'i' THEN 'index' WHEN 'S' THEN 'sequence' WHEN
's' THEN 'special' WHEN 'c' THEN 'composite
Sam Mason wrote:
On Tue, Sep 01, 2009 at 04:36:25PM +, Joseph Shraibman wrote:
Description:CASE returns ELSE value always when type is char
I think it's just silently truncating the literal to a single character.
[local]:playpen= select c.relkind, CASE c.relkind WHEN 'r' THEN
Joseph Shraibman j...@selectacast.net writes:
So the type of what is in the ELSE clause determines the type of the output?
If all the other branches are unknown literals, yes.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
Tom Lane t...@sss.pgh.pa.us wrote:
Joseph Shraibman j...@selectacast.net writes:
So the type of what is in the ELSE clause determines the type of
the output?
If all the other branches are unknown literals, yes.
What's the best place to look to get a handle on what the benefits are
of
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Joseph Shraibman j...@selectacast.net writes:
So the type of what is in the ELSE clause determines the type of
the output?
If all the other branches are unknown literals, yes.
What's the best place to
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Joseph Shraibman j...@selectacast.net writes:
So the type of what is in the ELSE clause determines the type of
the output?
If all the other branches are unknown
On Tue, 2009-09-01 at 13:49 -0500, Kevin Grittner wrote:
I figured that; I'm just trying to understand what seems to me like an
odd wart on the type system. I figure I must be missing something
important, so I'd kinda like to find out what that is.
If I understand your question, you're
23 matches
Mail list logo
