Jerry Levan writes:
> On Feb 17, 2012, at 4:21 PM, Tom Lane wrote:
>> I beg your pardon?
> Sorry, they do not appear in *my* 'yum update' or yumex or the software
> update program.
Huh. Something broken on your end, but what? The only thing that looks
funny to me in your output is
> [jerry@b
On Feb 17, 2012, at 4:21 PM, Tom Lane wrote:
> Jerry Levan writes:
>> Seems like Postgresql 9.1.2 has been out for a while but it has
>> not appeared in the updates for Fedora 16.
>
> I beg your pardon?
Sorry, they do not appear in *my* 'yum update' or yumex or the software update
program.
I
Jerry Levan writes:
> Seems like Postgresql 9.1.2 has been out for a while but it has
> not appeared in the updates for Fedora 16.
I beg your pardon?
https://admin.fedoraproject.org/updates/FEDORA-2012-0346/postgresql-9.1.2-2.fc16
https://admin.fedoraproject.org/updates/FEDORA-2011-16803/postgre
On 02/17/2012 08:01 AM, Marti Raudsepp wrote:
On Fri, Feb 17, 2012 at 17:13, Adrian Klaver wrote:
Why not use:
" SELECT * FROM WHERE CAST(Table.ID as TEXT) LIKE '1%' "
as the MySQL query also? MySQL supports the CAST function.
Nope, trying to use CAST() in an interoperable manner is a lost
On 2/17/2012 2:49 PM, Merlin Moncure wrote:
On Fri, Feb 17, 2012 at 2:32 PM, Andy Colson wrote:
On 2/17/2012 2:11 PM, Pavel Stehule wrote:
Hello
PostgreSQL has no table data type. You can use a array of records instead
and then
select fx((select array(select * from tab)));
select fx(arra
On Fri, Feb 17, 2012 at 2:32 PM, Andy Colson wrote:
> On 2/17/2012 2:11 PM, Pavel Stehule wrote:
>>
>> Hello
>>
>> PostgreSQL has no table data type. You can use a array of records instead
>>
>> and then
>>
>> select fx((select array(select * from tab)));
select fx(array(select t from tab t));
f
On 2/17/2012 2:11 PM, Pavel Stehule wrote:
Hello
PostgreSQL has no table data type. You can use a array of records instead
and then
select fx((select array(select * from tab)));
regards
Pavel Stehule
2012/2/17 Andy Colson:
Hi all,
Trying to clean up some data so I wrote myself a function
Hello
PostgreSQL has no table data type. You can use a array of records instead
and then
select fx((select array(select * from tab)));
regards
Pavel Stehule
2012/2/17 Andy Colson :
> Hi all,
>
> Trying to clean up some data so I wrote myself a function which will insert
> the new stuff okay b
Hi,
Anybody with any ideas on using Postgres on ARM CORTEX A8 based processors.. ?
Thanks!
Jay
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Jayashankar K B
Sent: 16 February 2012 PM 04:00
To: pgsql-general@postgresql.org
Subject: [GENERAL] Po
Hi all,
Trying to clean up some data so I wrote myself a function which will
insert the new stuff okay but the existing data... I'm not sure how to
run it through the function.
To make life a little simpler on myself, the old data is in table
webserv2 and the new data will go into table webs
I guess I am feeling a bit cranky today :(…
Seems like Postgresql 9.1.2 has been out for a while but it has
not appeared in the updates for Fedora 16.
Today I cruised koji.fedoraproject.org and noticed that a
set of rpms appear to been built by , ummm, 'tgl' back in
early January.
Does anyone kn
On Fri, Feb 17, 2012 at 9:22 AM, Marti Raudsepp wrote:
> On Fri, Feb 17, 2012 at 18:19, Scott Marlowe wrote:
>> Have you tried casting to varchar(1000) or something like that?
>
> MySQL's CAST() doesn't accept varchar or varchar(N). It accepts char,
> which behaves like varchar.
It's a shame you
On 17 February 2012 17:19, Scott Marlowe
> Have you tried casting to varchar(1000) or something like that?
Don't MySQL's varchars only go to 255? That's why every MySQL database
uses blobs for text data, isn't it?
--
If you can't see the forest for the trees,
Cut the trees and you'll see there i
On Fri, Feb 17, 2012 at 18:19, Scott Marlowe wrote:
> Have you tried casting to varchar(1000) or something like that?
MySQL's CAST() doesn't accept varchar or varchar(N). It accepts char,
which behaves like varchar.
Regards,
Marti
--
Sent via pgsql-general mailing list (pgsql-general@postgresq
On Fri, Feb 17, 2012 at 17:31, David W Noon wrote:
> The words to search for are "Cartesian product". This is the way
> RDBMSes have handled unconstrained implicit joins since the days of
> SQL/DS.
Yeah, that's what Jack was confused about -- it's actually *not* a
cartesian product. It simply st
On Fri, Feb 17, 2012 at 9:01 AM, Marti Raudsepp wrote:
> On Fri, Feb 17, 2012 at 17:13, Adrian Klaver wrote:
>> Why not use:
>> " SELECT * FROM WHERE CAST(Table.ID as TEXT) LIKE '1%' "
>>
>> as the MySQL query also? MySQL supports the CAST function.
>
> Nope, trying to use CAST() in an interope
On Fri, Feb 17, 2012 at 17:13, Adrian Klaver wrote:
> Why not use:
> " SELECT * FROM WHERE CAST(Table.ID as TEXT) LIKE '1%' "
>
> as the MySQL query also? MySQL supports the CAST function.
Nope, trying to use CAST() in an interoperable manner is a lost cause.
Sadly MySQL and PostgreSQL don't ag
On Thu, 16 Feb 2012 13:19:16 -0600, Jack Christensen wrote about
[GENERAL] Set returning functions in select column list:
[snip]
> I really don't understand what is going on here. I have checked
> Google and the PostgreSQL docs, but it appears either I do not know
> the key words to search for or
On Thu, 16 Feb 2012 13:19:16 -0600, Jack Christensen wrote about
[GENERAL] Set returning functions in select column list:
[snip]
> I really don't understand what is going on here. I have checked
> Google and the PostgreSQL docs, but it appears either I do not know
> the key words to search for or
David Johnston writes:
> On Feb 16, 2012, at 14:19, Jack Christensen wrote:
>> Can someone explain how set returning functions in a select clause work?
> You apparently just did...it CROSS JOINs except in the special case where
> multiple functions each return the same number of records (genera
On Friday, February 17, 2012 5:01:47 am premanand wrote:
> In MySQL the below query is executing properly.
>
> SELECT * FROM WHERE (Table.ID LIKE '1%')
>
> But when i try to execute the above query in Postgres, i get the following
> Exception "org.postgresql.util.PSQLException: ERROR: operator d
On Feb 16, 2012, at 14:19, Jack Christensen wrote:
> Can someone explain how set returning functions in a select clause work?
You apparently just did...it CROSS JOINs except in the special case where
multiple functions each return the same number of records (generally due to
them all operating
In MySQL the below query is executing properly.
SELECT * FROM WHERE (Table.ID LIKE '1%')
But when i try to execute the above query in Postgres, i get the following
Exception "org.postgresql.util.PSQLException: ERROR: operator does not
exist: integer ~~ unknown Hint: No operator matches the giv
thanks, it looks exactly as I was searching for
On Thu, Feb 16, 2012 at 23:05, Marti Raudsepp wrote:
> On Thu, Feb 16, 2012 at 18:53, sodik
> wrote:
> > is there any way how to check that postgres 9.1 is currently in backup
> > mode?
>
> You can check the existence of the "backup_label" file in
Dear PGSQL Masters!
I got a new project: porting a DBASE based application to PGSQL. Some
theoretic question I have before I coding/typing.
OS: Win, IDE: Delphi.
Preface:
Delphi uses TDataSet-s (every of them have records/rows).
When use Post method to save the actual record. In DBASE or flat ta
25 matches
Mail list logo
