Sam Mason 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 standard type char(1)
The following bug has been logged online:
Bug reference: 5035
Logged by:
Email address: tkar...@ultimo.pl
PostgreSQL version: 8.3.6
Operating system: Linux
Description:cast 'text' to 'name' doesnt work in plpgsql function
Details:
Comparing 'text' to 'name' in plpg
The following bug has been logged online:
Bug reference: 5036
Logged by: Dennis Seran
Email address: dse...@novonics.com
PostgreSQL version: 8.4
Operating system: Windows XP and RHEL
Description:Advisory locks have unexpected behavior
Details:
Here is the scenario t
On Fri, Sep 4, 2009 at 11:15 AM, 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) doesn't
> actually help us much to decide i
Dennis Seran wrote:
> - Client B again prompts the command pg_try_advisory_lock_shared(12345) in
> an attempt to reobtain the shared lock(12345) but returns false and fails to
> obtain the shared lock (SHOULDN'T THIS CLIENT BE ABLE TO OBTAIN THE SHARED
> LOCK?)
No; it gets to sleep until after cl
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)
> doesn't actually help us much to decide if an error should be thrown
>
On Fri, Sep 4, 2009 at 11:59 AM, 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)
>> doesn't act
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)
> >
tkar...@ultimo.pl wrote:
> Without casting function executes much slower:
>
> CREATE OR REPLACE FUNCTION table_exists(tblname text) RETURNS boolean AS '
> DECLARE
> exists boolean;
> BEGIN
> SELECT 1 INTO exists FROM pg_class WHERE relname = name($1);
> RETURN exists;
> END;
> ' LAN
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:
http://www.
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 initialize a value of "char" type.
>
> As I read the semantics of the CASE predic
Alvaro Herrera writes:
> tkar...@ultimo.pl wrote:
>> Without casting function executes much slower:
> If you're looking for a speedy answer, try a SQL function, not plpgsql.
He's still going to need the cast to name. It's not a bug, it's just
how things work: the indexes on pg_class support nam
Sam Mason 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 better. In my v
Sam Mason 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 WHEN TRUE TH
"Kevin Grittner" 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 in the above CASE
>
Tom Lane 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' else
'a'::char(1)
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
Alvaro Herrera writes:
> Tom Lane wrote:
>> I'm inclined to think that the don't-create-a-table-entry behavior in
>> pgstat_recv_vacuum and pgstat_recv_analyze should just be dropped.
> I think this business about supressing pgstat entries started because of
> autovacuum. I wasn't too fond of th
The following bug has been logged online:
Bug reference: 5037
Logged by: Rob Resendez
Email address: rob.resen...@cpsinet.com
PostgreSQL version: 8.3.7
Operating system: Linux
Description:jdbc bug \u
Details:
resultSet.getObject() returns \ufffd when I expect to
On Thu, Sep 3, 2009 at 5:21 PM, Diego de Lima wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5034
> Logged by: Diego de Lima
> Email address: diego_de_l...@hotmail.com
> PostgreSQL version: 8.3.7
> Operating system: Linux Fedora 10
> Description:
The following bug has been logged online:
Bug reference: 5038
Logged by: Luke Koops
Email address: luke.ko...@entrust.com
PostgreSQL version: 8.3.7
Operating system: Windows 2003 Server Enterprise Edition
Description:WAL file is pending deletion in pg_xlog folder, thi
On Tue, Aug 25, 2009 at 8:15 AM, Lampa wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5010
> Logged by: Lampa
> Email address: lamp...@gmail.com
> PostgreSQL version: 8.4.0
> Operating system: Debian testing/unstable
> Description: perl iconv fun
22 matches
Mail list logo
