Hey folks,
I have question really for all mighty developers, but don't want to
spam -hackers with it.
why :
select * from foo where X in (1,1,1,1,1,1,1,1) --- same values in search.
or select * from foo where (x,y) in ((1,2),(1,2),(1,2),(1,2),(1,2),(1,2),(1,2));
never gets optimized by planner,
I wonder if this is an SQL limitation or something I'm missing in the
PG manual, but I need to run an update on my database (to replace the
value of a column to match a new design structure).
Due to the new business logic, the replaced value of a field may end
up being already present in the data
On Mon, Jan 26, 2009 at 2:09 PM, Phoenix Kiula wrote:
> I wonder if this is an SQL limitation or something I'm missing in the
> PG manual, but I need to run an update on my database (to replace the
> value of a column to match a new design structure).
>
> Due to the new business logic, the replac
On Mon, Jan 26, 2009 at 9:45 PM, Matthias Karlsson wrote:
> On Mon, Jan 26, 2009 at 2:09 PM, Phoenix Kiula
> wrote:
>> I wonder if this is an SQL limitation or something I'm missing in the
>> PG manual, but I need to run an update on my database (to replace the
>> value of a column to match a ne
2009/1/26 Grzegorz Jaśkiewicz
> Hey folks,
>
> I have question really for all mighty developers, but don't want to
> spam -hackers with it.
>
> why :
> select * from foo where X in (1,1,1,1,1,1,1,1) --- same values in search.
> or select * from foo where (x,y) in
> ((1,2),(1,2),(1,2),(1,2),(1,2),
On 1/24/09, Ian Sollars wrote:
> Hello everyone,
>
> I've got some questions about dblink that I couldn't find answers to in the
> documentation. Any help would be much appreciated.
>
> I need to invoke a function on a remote server that returns either void or
> text, and I'm trying to find a nice
On Mon, Jan 26, 2009 at 1:58 PM, Filip Rembiałkowski
wrote:
> 2009/1/26 Grzegorz Jaśkiewicz
>>
>> Hey folks,
>>
>> I have question really for all mighty developers, but don't want to
>> spam -hackers with it.
>>
>> why :
>> select * from foo where X in (1,1,1,1,1,1,1,1) --- same values in search.
On Mon, Jan 26, 2009 at 2:53 PM, Phoenix Kiula wrote:
> On Mon, Jan 26, 2009 at 9:45 PM, Matthias Karlsson wrote:
>> On Mon, Jan 26, 2009 at 2:09 PM, Phoenix Kiula
>> wrote:
>>> I wonder if this is an SQL limitation or something I'm missing in the
>>> PG manual, but I need to run an update on m
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= writes:
> why :
> select * from foo where X in (1,1,1,1,1,1,1,1) --- same values in search.
> never gets optimized by planner, etc ?
We actually did that, before 8.0 or thereabouts. It was removed because
it cost a lot of planner cycles for *every* query, and
Take a stab at plproxy if you want to remotly call functions. Should be much
better suited than dblink for that.
Regards
Asko
On Mon, Jan 26, 2009 at 4:07 PM, Merlin Moncure wrote:
> On 1/24/09, Ian Sollars wrote:
> > Hello everyone,
> >
> > I've got some questions about dblink that I couldn't
Postgres 8.3.3 on 2.6.21
Some sort of corruption happened overnight and borked things on a server.
Normally I'd just restore and go, but the DB was moved about 6 weeks ago and it
looks like the backup task was not, shame on me. I really just need 2 very
small tables out of this and then I can
dave sale writes:
> psql: FATAL: could not open relation with OID 3606
> I'm pretty sure the file is there for 3606, but it's another system index
> from what I can tell:
> postgres=> select oid,* from pg_class where oid=3606;
> oid | relname | relnamespace | reltype | rel
Thanks for your help;
template1=# select * from pg_class where oid=3606;
relname | relnamespace | reltype | relowner | relam |
relfilenode | reltablespace | relpages | reltuples | reltoastrelid |
reltoastidxid | relhasindex | relisshared | relkind | relnatts | relchecks |
r
This call is going out to PostgreSQL enthusiasts. We are seeking
volunteers to assist the PostgreSQL booth for this years Southern
California Linux Expo: http://scale7x.socallinuxexpo.org
The Exhibit hall will be open on Saturday the February 21st and Sunday
the 22nd between the hours of 10am and
bgrosper...@laposte.net
Bernard Grosperrin
BGSoftFactory
Bureau/Domicile 09 53 41 58 18
Mobile 06 75 13 97 17
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
My notion is to do a character mode database dump as SQL statements and
then load into the new version by execution of psql against the sql
STATEMENTS.
What are the "gotchas" we can expect with this approach?
When I say 'ancient' I mean v7.1.3 and the target is v8.3.5.
--
Sent via pgsql-genera
On 26/01/2009 21:37, Dann Corbit wrote:
> My notion is to do a character mode database dump as SQL statements and
> then load into the new version by execution of psql against the sql
> STATEMENTS.
>
> What are the "gotchas" we can expect with this approach?
>
> When I say 'ancient' I mean v7.1.3
On 26/01/2009 21:42, Raymond O'Donnell wrote:
> Off the top of my head, I have a memory that constraints were
Sorry, I meant to say "...foreign key constraints..."
R.
--
Raymond O'Donnell, Director of Music, Galway Cathedral, Irela
Dann Corbit wrote:
My notion is to do a character mode database dump as SQL statements and
then load into the new version by execution of psql against the sql
STATEMENTS.
What are the "gotchas" we can expect with this approach?
When I say 'ancient' I mean v7.1.3 and the target is v8.3.5.
Ass
On Mon, Jan 26, 2009 at 2:20 PM, Bernard Grosperrin
wrote:
To make changes to your subscription, go here:
> http://www.postgresql.org/mailpref/pgsql-general
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mai
In discussing foreign key constraints the manual makes the following
statement about the difference between RESTRICT and NO ACTION.
"(The essential difference between these two choices is that |NO ACTION|
allows the check to be deferred until later in the transaction, whereas
|RESTRICT| does n
Bill Todd wrote:
In discussing foreign key constraints the manual makes the following
statement about the difference between RESTRICT and NO ACTION.
"(The essential difference between these two choices is that |NO
ACTION| allows the check to be deferred until later in the
transaction, whereas
Bill Todd writes:
> In discussing foreign key constraints the manual makes the following
> statement about the difference between RESTRICT and NO ACTION.
> "(The essential difference between these two choices is that |NO ACTION|
> allows the check to be deferred until later in the transaction,
"Dann Corbit" writes:
> My notion is to do a character mode database dump as SQL statements and
> then load into the new version by execution of psql against the sql
> STATEMENTS.
> What are the "gotchas" we can expect with this approach?
> When I say 'ancient' I mean v7.1.3 and the target is v8.3
On Jan 26, 2009, at 6:33 PM, Tom Lane wrote:
"Dann Corbit" writes:
My notion is to do a character mode database dump as SQL statements
and
then load into the new version by execution of psql against the sql
STATEMENTS.
What are the "gotchas" we can expect with this approach?
When I say 'anc
Tom Lane wrote:
"Dann Corbit" writes:
My notion is to do a character mode database dump as SQL statements and
then load into the new version by execution of psql against the sql
STATEMENTS.
What are the "gotchas" we can expect with this approach?
When I say 'ancient' I mean v7.1.3 and the targe
On Mon, Jan 26, 2009 at 10:37 PM, Dann Corbit wrote:
> My notion is to do a character mode database dump as SQL statements and
> then load into the new version by execution of psql against the sql
> STATEMENTS.
>
> What are the "gotchas" we can expect with this approach?
>
> When I say 'ancient' I
On Tue, 2009-01-27 at 04:28 +0100, marcin mank wrote:
> On Mon, Jan 26, 2009 at 10:37 PM, Dann Corbit wrote:
> > My notion is to do a character mode database dump as SQL statements and
> > then load into the new version by execution of psql against the sql
> > STATEMENTS.
> >
> > What are the "got
On Mon, Jan 26, 2009 at 06:45:55PM -0800, Steve Atkins wrote:
> On Jan 26, 2009, at 6:33 PM, Tom Lane wrote:
>> "Dann Corbit" writes:
>>> My notion is to do a character mode database dump as SQL
>>> statements and then load into the new version by execution of
>>> psql against the sql STATEMENTS.
David Fetter writes:
> I think you may be thinking of the situation where foreign keys were
> implemented as visible triggers, and the contrib/adddepend script,
> which was removed (IIRC) in 8.2.
We replaced it with some hacks in CREATE TRIGGER, so theoretically that
conversion should still work.
Hi,
I have a table with BIG SERIAL field as Primary KEY. During high load,
entries in the BIG SERIAL field are jumped. One could see a row with
1367 and expecting the next INSERT to be 1368, one would end up
getting 1369.
Please is this normal?
Regards,
Chris
--
Sent via pgsql-general mailing
db.subscripti...@shepherdhill.biz wrote:
>
> Hi,
>
> I have a table with BIG SERIAL field as Primary KEY. During high load,
> entries in the BIG SERIAL field are jumped. One could see a row with
> 1367 and expecting the next INSERT to be 1368, one would end up
> getting 1369.
>
> Please is this n
Bill Moran wrote:
> db.subscripti...@shepherdhill.biz wrote:
>> Hi,
>>
>> I have a table with BIG SERIAL field as Primary KEY. During high load,
>> entries in the BIG SERIAL field are jumped. One could see a row with
>> 1367 and expecting the next INSERT to be 1368, one would end up
>> getting 1369
In response to db.subscripti...@shepherdhill.biz :
> Hi,
>
> I have a table with BIG SERIAL field as Primary KEY. During high load,
> entries in the BIG SERIAL field are jumped. One could see a row with
> 1367 and expecting the next INSERT to be 1368, one would end up
> getting 1369.
>
> Please i
Harald Armin Massa wrote:
> 4.) it seems to be no longer "cool" to have your data below Program
> Files / Program Files (x86)
> The default as of know is \ProgramData\
I think all of those directories are only for executable files
and not good to store any data. Is it safe to create database cl
35 matches
Mail list logo
