>
> Basically you are getting Cartesian joins on the row output of
> unnest()
Well that's what I expected too. Except look at this example, after you
delete c:
testdb=# DELETE FROM t2 where val='c';
DELETE 1
testdb=# SELECT * from t1, t2;
val | val
-+-
1 | a
1 | b
2 | a
2 |
2013/3/27 Ken Tanzer
> Basically you are getting Cartesian joins on the row output of
>> unnest()
>
>
> Well that's what I expected too. Except look at this example, after you
> delete c:
>
> testdb=# DELETE FROM t2 where val='c';
> DELETE 1
> testdb=# SELECT * from t1, t2;
> val | val
> -+
On 27/03/13 20:36, Ian Lawrence Barwick wrote:
2013/3/27 Ken Tanzer mailto:ken.tan...@gmail.com>>
Basically you are getting Cartesian joins on the row output of
unnest()
Well that's what I expected too. Except look at this example,
after you delete c:
testdb=# DE
Hi,
You can try:
SELECT c1, c2 FROM
(
WITH a AS
(
SELECT row_number() OVER(),* FROM unnest(array['a','b', 'c', 'd']) c1
),
b AS
(
SELECT row_number() OVER(),* FROM unnest(array['1','2', '3']) c2
)
SELECT * FROM a LEFT JOIN b USING (row_number)
UNION
SELECT * FROM a RIGHT JOIN b USING (row_number)
Tom Lane, 26.03.2013 17:16:
The lack of any prohibition to the contrary means there is no way to
argue that the code you showed previously violates the spec; thus,
a database that fails to accept it is rejecting spec-compliant DDL.
I'm not claiming that the spec is violated...
(And I'm not comp
Alban Hertroys, 26.03.2013 17:17:
It can make sense during a maintenance window, if you create a new
(redundant) FK constraint concurrently to replace the existing one.
If you'd first remove the existing constraint, you're allowing FK
violations until the new constraint has finished creating its
Gavin Flower writes:
> The rule appears to be,
> where N_x & N_y are the number of entries returned for x & y:
> N_result = is the smallest positive integer that has N_x & N_y as factors.
Right: if there are multiple set-returning functions in a SELECT list,
the number of rows you get is the leas
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> is there any way to use a module within a pltcl script, i.e. have
> load /path/to/mystuff.so
> or
> package require mystuff
> in a script.
You can load tcl code by putting it in the pltcl_modules tables. See:
http://www.postgresql.org/docs/9
On 2013-03-26 19:28, Kevin Grittner wrote:
>> Why are full vacuums excluded from this statistic? It looks like there's
>> no way to get the date of the last manual vacuum, if only full vacuums
>> are performed.
>
> Because FULL is a bit of a misnomer -- there are important things a
> non-FULL vacu
2013/3/27 Tom Lane :
> Gavin Flower writes:
>> The rule appears to be,
>> where N_x & N_y are the number of entries returned for x & y:
>> N_result = is the smallest positive integer that has N_x & N_y as factors.
>
> Right: if there are multiple set-returning functions in a SELECT list,
> the num
Thomas Kellerer wrote:
> Alban Hertroys, 26.03.2013 17:17:
>> It can make sense during a maintenance window, if you create a new
>> (redundant) FK constraint concurrently to replace the existing one.
>> If you'd first remove the existing constraint, you're allowing FK
>> violations until the new c
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: RIPEMD160
>>
>>
>> > is there any way to use a module within a pltcl script, i.e. have
>> > load /path/to/mystuff.so
>> > or
>> > package require mystuff
>> > in a script.
>>
>> You can load tcl code by putting it in the pltcl_modules tables.
Hello,
I have a database which is bloated because of vacuum full, so you find indexes
bigger than the table itself.
I have dumped this database and restored it without reindixing and it was
extremely slow. So, my question what is the relation between bloated database
and pg_restore.
Rega
Hi,
Sorry for asking such a newbie-question, I've used a search engine -
however I haven't found what I am searching for.
Is there any way to listen to NOTIFY in php without polling using a
callback or blocking call?
I've only found pg_get_notify(), however it requires polling as far as
I underst
In response to Clemens Eisserer :
>
> Is there any way to listen to NOTIFY in php without polling using a
> callback or blocking call?
Not at this time.
--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/
--
Sent via pgsql-general mailing list (pgsql-gen
Hi Bill,
>> Is there any way to listen to NOTIFY in php without polling using a
>> callback or blocking call?
>
> Not at this time.
Too bad ... Thanks for the confirmation.
I'll try to invoke a native libpg binary which stays alive until a
NOTIFY is received, should do the trick in case update-f
Hi,
What is the main goal?
even using libpg - you need to call pg notify... Doc says, just using
libpgtcl would be possible to get Notify event - without checking from time
to time...
Kind Regards,
Misa
2013/3/27 Clemens Eisserer
> Hi Bill,
>
> >> Is there any way to listen to NOTIFY in ph
Hi Misa
> What is the main goal?
The main goal is to perform some inter-system communication in the
case some rows in one table are updated (very seldom event).
> even using libpg - you need to call pg notify... Doc says, just using
> libpgtcl would be possible to get Notify event - without chec
Hi Clemens,
Well, I am not sure what you mean by polling...
But Example shows - that C app - actually asks all the time to get
notify... when gets something more then 4 times - exit... until 4 times
loops...
The same you can achieve with PHP...
But I am not sure that is the main goal...
My gue
In contrast to certain other open-source databases, PostgreSQL leans
toward protecting data from surprises and erroneous input, i.e.
rejecting a date of 2013-02-31 instead of arbitrarily assigning a date
of 2013-03-03. Similar "throw error" instead of "take a guess"
philosophy applies to numeri
Hi Misa
> But Example shows - that C app - actually asks all the time to get notify...
> when gets something more then 4 times - exit... until 4 times loops...
> The same you can achieve with PHP...
As far as I understood, with php I have to query the server again and
again, and pg_get_notify wil
Hello,
On Wed, Mar 27, 2013 at 9:56 AM, salah jubeh wrote:
> I have a database which is bloated because of vacuum full, so you find
> indexes bigger than the table itself.
Table can not be bloated because of vacuum full, it removes bloat from
the table and its indexes. The fact that an index is
Sergey Konoplev writes:
> On Wed, Mar 27, 2013 at 9:56 AM, salah jubeh wrote:
>> I have a database which is bloated because of vacuum full, so you find
>> indexes bigger than the table itself.
> Table can not be bloated because of vacuum full, it removes bloat from
> the table and its indexes.
I found a workaround: domain type defined as: CREATE DOMAIN currency AS
numeric(16,4);
Thank you!
24 matches
Mail list logo
