On Mon, Sep 14, 2009 at 10:22:34AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > It seems like regardless of this discussion you oughtn't to be able to
> > store a NULL into that table column. But maybe I'm just confused.
>
> The system is relying on the not-unreasonable assumption that if it
On Mon, Sep 14, 2009 at 10:54:07AM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > the deeper problem seems to be that the table was created as:
> >
> > create table test (a tstdom);
> >
> > and not as:
> >
> > create table test (a tstdom n
On Mon, Sep 14, 2009 at 11:16:23AM -0400, Robert Haas wrote:
> I haven't read the code in this area, but for what it's worth, I guess
> I lean toward the view that treating a row of NULLs as being the same
> thing as an undecorated NULL does not make very much sense.
I agree; when compared to most
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 bi
On Fri, Sep 04, 2009 at 12:26:19PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > Kevin Grittner wrote:
> >> test=# select case when true then 'xxx' else 'a'::"char" end from t;
> >
> > 'xxx' is being used to initia
On Fri, Sep 04, 2009 at 10:59:48AM -0500, Kevin Grittner wrote:
> Tom Lane 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)
> >
On Wed, Sep 02, 2009 at 02:59:54PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > CREATE VIEW v (c) AS
> > SELECT NULL;
> >
> > PG allows it, but the resulting view seems somewhat unusable.
>
> I'm not sure whether the only place the s
On Wed, Sep 02, 2009 at 02:41:32PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
>
> > I'd always thought '2001-01-01' was a valid date literal, seems the
> > standard has required it to be prefixed by DATE at least back to
> > SQL92.
>
> Yep.
On Wed, Sep 02, 2009 at 12:54:03PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > If we did follow Kevin's request directly, should we also be
> > specifying the type of NULL?
>
> I don't *think* the SQL standard requires that, and barring that I
> don&#
On Wed, Sep 02, 2009 at 01:37:20PM -0500, Kevin Grittner wrote:
> That still seems to be the case in the draft of the 2003 standard I
> have:
>
> ::=
>
> |
> |
> |
> |
> |
> |
> ::=
> [ ]
> [ ... ]
> [ { [ ... ]
> }... ]
>
> The ball's in your court to
On Wed, Sep 02, 2009 at 01:55:28PM -0500, Kevin Grittner wrote:
> So the behavior of the "char" type is anomalous in this regard? Other
> character-based types behave like varchar (which has the behavior I
> would expect here)? That is encouraging. Why isn't the behavior of
> "char" in this rega
On Wed, Sep 02, 2009 at 01:27:35PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > you were requiring the types of literals that happened to be
> > enclosed in quotes to have their type ascribed, so why not the NULL
> > literal?
>
> Well, unless things have ch
On Wed, Sep 02, 2009 at 12:54:03PM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > If we did follow Kevin's request directly, should we also be
> > specifying the type of NULL?
>
> I don't *think* the SQL standard requires that, and barring that I
> don&#
On Wed, Sep 02, 2009 at 01:19:07PM -0400, Tom Lane wrote:
> Sam Mason writes:
> > ... For example:
>
> > CREATE FUNCTION add(int,int) RETURNS int LANGUAGE sql
> > AS $$ SELECT $1 + $2; $$;
>
> > CREATE FUNCTION add(int,int,int DEFAULT NULL) RET
On Wed, Sep 02, 2009 at 12:36:00PM -0400, Robert Haas wrote:
> On Wed, Sep 2, 2009 at 11:55 AM, Sam Mason wrote:
> > In fact it doesn't seem to want to play ball at all. Even given the
> > apparently unambiguous:
> >
> > SELECT 1+add(1,2);
> > or
> >
On Wed, Sep 02, 2009 at 03:50:05PM +0100, Greg Stark wrote:
> Perhaps we should stop thinking of "unknown" as, er, "unknown" and
> think of it as "text literal". A text literal has implicit casts to
> every data type but a normal text string has to be explicitly cast.
How does that help things? Y
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 +
-
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'
On Mon, Aug 31, 2009 at 07:26:59PM +0200, Pavel Stehule wrote:
> 2009/8/31 Sam Mason :
> > The more awkward case (to me anyway) is that the standard says (1,NULL)
> > IS NULL should evaluate to TRUE.
>
> what?
>
> only (NULL, NULL) IS NULL is true
Bah, sorry you&#
On Fri, Aug 28, 2009 at 02:06:02PM -0400, Merlin Moncure wrote:
> 3) If we decide the sql standard is correct, so that (null, null) is
> null == true, then we should observe rule 1 and make things work in
> consistent way. This means, for example, that null::foo and (null,
> null)::foo should not
On Wed, Aug 26, 2009 at 02:55:37PM +, Ken Smith wrote:
> I also noted
> that if I try to run from the commandline that you use '/' in some of the
> program paths causing the OS to say it cannot find the file - "C:/Program
> Files/Java/jdk1.5.0_16/jre/bin/java.exe".
I'm pretty sure that Windows
On Thu, May 29, 2008 at 07:01:46AM +, Jeferson Kasper wrote:
> the EXTRACT(field FROM source) function allows to use some kind of 'fields',
> and i need to know if a time (like '07:00') is after the midday(12:00) or
> not.
> I know i can resolve it implementing some function like "select
> ('07
On Mon, Apr 28, 2008 at 02:14:17PM +0200, Nicolas ZABOURI wrote:
> My server is down and all my dump aren't make.
> How can make for re-install the data on a new install of the server ?
If you can get another copy of 7.4 installed that's built for the same
processor as the database was originally
On Sun, Apr 20, 2008 at 08:17:50PM +0200, Zdenek Kotala wrote:
> Roman Kononov napsal(a):
> >The below test cases show the obvious inconsistency between different
> >integer types.
>
> It seems to be OK regarding how C shift operator works. Try
Yes, but I interpret this behaviour as not being ver
On Sun, Apr 20, 2008 at 12:27:38PM -0400, Tom Lane wrote:
> Sam Mason <[EMAIL PROTECTED]> writes:
> > Wouldn't it be easy to put some code like this in:
> > if (arg2 < 16)
> > return PG_RETURN_INT16(arg1 << arg2);
> > return PG_RETURN_INT16(0)
On Sat, Apr 19, 2008 at 11:26:57AM -0400, Tom Lane wrote:
> Roman Kononov <[EMAIL PROTECTED]> writes:
> > The below test cases show the obvious inconsistency between different
> > integer types.
>
> [ shrug... ] The << and >> operators just expose the behavior of the
> local C compiler's shift o
On Thu, Apr 03, 2008 at 12:24:17AM +0200, Peter Eisentraut wrote:
> Jeff Dwyer wrote:
> > This works fine:
> > select 1 where current_date between '1900-3-3' and '1900-2-2';
> > This doesn't:
> > select 1 where current_date between coalesce(null,current_date) and
> > coalesce(null, '1900-1-2');
>
On Fri, Mar 28, 2008 at 01:43:25PM -0300, Euler Taveira de Oliveira wrote:
> [EMAIL PROTECTED] wrote:
> >a column definition list is required for functions returning "record"
> >It seems a BUG
> >
> I don't think so. We can say it is a missing feature. As stated in [1],
> record types don't have a
On Fri, Mar 14, 2008 at 08:53:08PM +, RGF wrote:
> PostgreSQL version: latest
do you mean 8.2.6, 8.3.0 or a latest version of some other series?
please try a little harder next time!!
> Description:sql table aliases do not work
they do whenever I use them! by the looks of your SQL yo
On Tue, Jan 01, 2008 at 04:29:47PM -0500, Tom Lane wrote:
> Sam Mason <[EMAIL PROTECTED]> writes:
> > I've just downloaded the source of tinyerp and had a look though and
> > this practice seems pretty endemic. They should really be using
> > to_char(dat
On Tue, Jan 01, 2008 at 08:11:01PM +, Ion wrote:
> Email address: [EMAIL PROTECTED]
lets hope Ion is subscribed! :)
> I tested PostgreSQL 8.3 beta4 with tinyerp and I have this problem:
> pg_catalog.substring(date, integer, integer) does not exist
This is most likely a bug in tinyerp. s
On Tue, Nov 06, 2007 at 10:00:43AM -0500, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Not sure that's enough of a use case to justify not banning it...
>
> Yeah, it probably is.
It's reasonably easy to do this instead:
CREATE TABLE foo (
one INTEGER NOT NULL UNIQUE
The following bug has been logged online:
Bug reference: 3723
Logged by: Sam Mason
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Linux
Description:dropping an index that doesn't refer to table's columns
Details:
Hi,
33 matches
Mail list logo
