Hello
It is clear that '' is a bad integer or timestamp representation
but during the user input NULLs are usually represented with empty strings
sometimes bunch of 'if empty' instructions grows huge
(and in case of casting to timestamp apostrophes make sense)
Why you prohibit casting ''::int
On Sun, Jun 06, 2004 at 06:40:56PM -0400, Tom Lane wrote:
> Jeff Boes <[EMAIL PROTECTED]> writes:
> > This seems ... well, counter-intuitive at least:
> > (using Pg 7.4.1)
>
> > # select to_char('4 minutes'::interval -
> > '5 minutes 30 seconds'::interval, 'mi:ss');
>
> > to_char
> > -
On Monday, 07 June 2004 09:52, Karel Zak wrote:
> http://www.postgresql.org/docs/7.4/static/functions-formatting.html
>
> Warning: to_char(interval, text) is deprecated and should not be
> used in newly-written code. It will be removed in the next version.
This is news for me. Are there any
On Mon, Jun 07, 2004 at 11:08:37AM +0200, Stefan Weiss wrote:
> On Monday, 07 June 2004 09:52, Karel Zak wrote:
> > http://www.postgresql.org/docs/7.4/static/functions-formatting.html
> >
> > Warning: to_char(interval, text) is deprecated and should not be
> >
On Mon, Jun 07, 2004 at 10:37:44 +0400,
sad <[EMAIL PROTECTED]> wrote:
> Hello
>
> It is clear that '' is a bad integer or timestamp representation
>
> but during the user input NULLs are usually represented with empty strings
> sometimes bunch of 'if empty' instructions grows huge
> (and in c
On Mon, 7 Jun 2004, sad wrote:
> It is clear that '' is a bad integer or timestamp representation
>
> but during the user input NULLs are usually represented with empty strings
> sometimes bunch of 'if empty' instructions grows huge
> (and in case of casting to timestamp apostrophes make sense)
Hello,
I have an instance where I have a series of pl/pgsql calls, that report stat
results to a common table. When other queries try to hit the stat table
(with DML commands; SELECT, INSERT, UPDATE, DELETE etc.) they are forced to
wait in a queue until the pl/pgsql has finished executing.
I'm trying to get my application to deduce foreign key relationships
automatically so it can perform appropriate joins for the user. I'm new
to information_schema and having problems getting what I want. Here is
a test script to be run on a database called "test."
-
Dear friends,
Postgres 7.3.4
How to find the last sunday/mon/sat of any given
month.
Thanks
Kumar
Hello all -
I need to return large result sets and therefore need a cursor with a small
fetch size (to avoid caching the entire query at once). However, it appears
that when a cursor is returned from a callable statement setFetchSize is
ignored.
I set up a query that crashes with outofMemoryErro
Richard Huxton <[EMAIL PROTECTED]> writes:
> Large table representing non-overlapping blocks:
> blocks(id int4, min varchar, max varchar)
> SELECT * FROM blocks WHERE 'ABCDE' BETWEEN min AND max;
> The estimator gets the wrong plan because it doesn't realise there's
> (at most) only one block tha
Kyle <[EMAIL PROTECTED]> writes:
> I'm trying to get my application to deduce foreign key relationships
> automatically so it can perform appropriate joins for the user. I'm new
> to information_schema and having problems getting what I want.
> ...
> I can determine all the primary key fields ni
Richard Huxton <[EMAIL PROTECTED]> writes:
> On Wednesday 25 February 2004 21:32, Tom Lane wrote:
>>> SELECT * FROM blocks WHERE 'ABCDE' BETWEEN min AND max;
>>
>> Even if it did realize that, it couldn't do much, because this query
>> isn't indexable as it stands.
> Well, it is in the sense that
13 matches
Mail list logo
