Hi There,
I've snipped a piece for the daily digest because I take issue with what's
asserted here as a reason for not allowing aliases in where clauses.
snipThis isn't just academic nit-picking either, because the SELECT
expressions might not be valid for rows that don't pass WHERE etc.
Ciao Rafal,
You can download the refreshed version of the patch:
http://archives.postgresql.org/message-id/1347983571.11539.14.ca...@greygoo.devise-it.lan
5. where do I get current-v9.3 from?
git clone git://git.postgresql.org/git/postgresql.git
cd postgresql
git checkout -b aefk
bzcat
Guilherme Rodrigues wrote:
I created one table so:
CREATE TABLE clima (
city char(80),
cprc int,
);
And have other table so:
CREATE TABLE city (
namechar(80),
other_thing int,
);
These SQL statements have syntax errors (comma after the last
On 19/09/2012 04:57, Chris Travers wrote:
Natural language semantics will get you into trouble though. After all,
I think Lisp follows natural language semantics remarkably closely if
your natural language is Irish Gaelic
Really? I haven't used Irish seriously since I left school -
On 18/09/2012, at 20:19, Jeff Janes wrote:
I think the one below will show an even larger discrepancy. You are
doing 2 casts for each comparison,
so I think the casts overhead will dilute out the comparison.
select count(distinct foo) from ( select cast(random() as varchar(14)) as foo
hello,
I've found a small logical issue while writing a migration script:
create table vtest (foo int);
create view vtest_v as select * from vtest;
drop table if exists vtest_v;
ERROR: vtest_v is not a table
drop view if exists vtest;
ERROR: vtest is not a view
this may be seen as a nice
On 09/19/2012 02:36 PM, Steve Haresnape wrote:
Since some dialects support the idiom and others don't there can't be
any compelling reason to withhold support. It's really a matter of style.
For my money the DRY style is better.
So you're saying that you want the implementation to effectively
On 09/19/2012 07:54 PM, Marc Mamin wrote:
hello,
I've found a small logical issue while writing a migration script:
create table vtest (foo int);
create view vtest_v as select * from vtest;
drop table if exists vtest_v;
ERROR: vtest_v is not a table
drop view if exists vtest;
ERROR:
On Wed, 2012-09-19 at 20:36 +0800, Craig Ringer wrote:
On 09/19/2012 02:36 PM, Steve Haresnape wrote:
Since some dialects support the idiom and others don't there can't be
any compelling reason to withhold support. It's really a matter of style.
For my money the DRY style is better.
So
-Original Message-
From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
ow...@postgresql.org] On Behalf Of Steve Haresnape
Sent: Wednesday, September 19, 2012 2:37 AM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] RFE: Column aliases in WHERE clauses
Hi There,
Em terça-feira, 18 de setembro de 2012 17h37min59s UTC-3, Guilherme Rodrigues
escreveu:
Hello. I want to change one table already created. Where the comand? thank
you.
Ok. Thank All.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
On 19/09/12 19:40, Albe Laurenz wrote:
Guilherme Rodrigues wrote:
I created one table so:
CREATE TABLE clima (
city char(80),
cprc int,
);
And have other table so:
CREATE TABLE city (
namechar(80),
other_thing int,
);
These SQL statements have
On Tue, Sep 18, 2012 at 7:47 PM, David Johnston pol...@yahoo.com wrote:
On Sep 18, 2012, at 20:21, Jean-Christophe Boggio postgre...@thefreecat.org
wrote:
I'm looking for an article that explains the difference between these
constructs IN POSTGRESQL (the rules seem to differ from one DB to
Le 19/09/2012 02:47, David Johnston a écrit :
There is no difference in your example. Conceptually though I
suggest using only table-table conditions in an ON clause and placing
any table-value conditions into the where.
This is how I use it usually.
The main time you get differences is
Le 19/09/2012 17:08, Merlin Moncure a écrit :
SELECT * FROM foo LEFT JOIN BAR ON foo.id = bar.id AND bar.col = 'something';
The difference here is that the filtering is now happening at join
time where the left join semantics are playing: always return foo and
return bar rows if and only if the
Good deduction Steve.
Looks like we are going to use the timestamp idea. This way, the ticket will
be open for sale again the second it's hold_until time lapses. The cronjob was
a close second, but there could be a lag-time between runs.
Thanks everyone for all the help.
--
Robert
Merlin Moncure mmonc...@gmail.com wrote:
By having the filtering in the where clause, the intended purpose
of the left join, to return every row of foo, is being defeated
and the join will behave like an inner join. The right way to do
it is:
SELECT * FROM foo LEFT JOIN BAR ON foo.id =
Hey Everyone,
We currently have a 9.1.5 postgres cluster running using streaming
replication. We have 3 nodes right now
2 - local that are setup with pacemaker for a HA master/slave set failover
cluster
1 - remote as a DR.
Currently we're syncing with the pretty standard routine
clear
On Wed, Sep 19, 2012 at 8:59 AM, Mike Roest mike.ro...@replicon.com wrote:
Hey Everyone,
We currently have a 9.1.5 postgres cluster running using streaming
replication. We have 3 nodes right now
2 - local that are setup with pacemaker for a HA master/slave set failover
cluster
1 -
Specifically what is the error?
psql (9.1.5)
Type help for help.
postgres=# select pg_start_backup('hotbackup',true);
pg_start_backup
-
61/B20
(1 row)
postgres=# select pg_start_backup('hotbackup',true);
ERROR: a backup is already in progress
HINT: Run pg_stop_backup()
Our sync script is setup to fail if the pg_start_backup fails as if it
fails for some other reason the sync won't be valid as the backup_label
file will be missing so the slave won't have the correct location to
restart from.
Originally I had gone down the road of changing the sync script such
Hello,
Actually I have sort of two questions rolled into one: when creating
custom data types, there's the option to implement *_send() and *_recv()
functions in addition to *_in() and *_out(); does pg_dump use them for
binary dumps, and, if not, what uses them? Are they only an optional
I have this query working :
select profil,count(og.name)
from ldap l
left join uidinoldgroups ug on l.uid=ug.uid left join oldgroups og on
og.id=ug.idgroupe and og.rne='0410030k' and og.type='g'
where l.profilgeneral='P'
and l.rne='0410030k'
group by l.profil
But if I put :
and
Is there any hidden issue with this that we haven't seen. Or does anyone
have suggestions as to an alternate procedure that will allow 2 slaves to
sync concurrently.
With some more testing I've done today I seem to have found an issue with
this procedure.
When the slave starts up after the
Just curious, is there a reason why you can't use pg_basebackup ?
On Wed, Sep 19, 2012 at 12:27 PM, Mike Roest mike.ro...@replicon.com wrote:
Is there any hidden issue with this that we haven't seen. Or does anyone
have suggestions as to an alternate procedure that will allow 2 slaves to
Performance.
On our production DB the fast-archiver transfers the datadir in about half
as much time as basebackup.
And since this happens on every failover (since clearing the datadir and
resyncing as if from scratch also takes about half the time as a rsync of
an existing datadir)
--Mike
On
On Tue, 2012-09-18 at 18:39 -0400, Tom Lane wrote:
Rafal Pietrak ra...@zorro.isa-geek.com writes:
postmaster/postmaster.o: In function `PostmasterMain':^M
postmaster.c:(.text+0x4bc8): undefined reference to `optreset'^M
tcop/postgres.o: In function `process_postgres_switches':^M
Had a simple function calling another function, and the final function
was doing raise log.
When I enabled normal stderr logging, with absurdly full
log_line_prefix, I got this:
#v+
a[psql] u[depesz] d[depesz] r[[local]] h[[local]] p[15444] t[2012-09-13
21:49:37 CEST] m[2012-09-13 21:49:37.840
Comments embedded between
David,
Thanks for the verbose explanations, really useful.
However, in my case :
- type is never NULL
Assuming you mean the og.type (i.e., the right-side of the join) even
though the column itself
On 20/09/12 03:08, Merlin Moncure wrote:
On Tue, Sep 18, 2012 at 7:47 PM, David Johnstonpol...@yahoo.com wrote:
On Sep 18, 2012, at 20:21, Jean-Christophe Boggiopostgre...@thefreecat.org
wrote:
I'm looking for an article that explains the difference between these
constructs IN POSTGRESQL
I am trying to write a generic upsert function in PL/pgSQL, in a way
that I can specify the table were I want to insert/update, the columns
whose values I want to specify, and the values to be inserted.
So far I have come up with a solution whose signature is:
CREATE OR REPLACE FUNCTION
Hi all
I'm wondering if there's any way to convince `to_char` to add a leading
zero to the hours in negative intervals. The current behaviour feels
wrong, in that FMHH24:MM and HH24:MM produce the same output for
negative intervals:
regress=# WITH x(i) AS (VALUES (INTERVAL
On 09/20/2012 01:01 AM, Ivan Voras wrote:
Hello,
Actually I have sort of two questions rolled into one: when creating
custom data types, there's the option to implement *_send() and *_recv()
functions in addition to *_in() and *_out(); does pg_dump use them for
binary dumps, and, if not, what
On 09/20/2012 05:37 AM, Lucas Clemente Vella wrote:
I am trying to write a generic upsert function in PL/pgSQL, in a way
that I can specify the table were I want to insert/update, the columns
whose values I want to specify, and the values to be inserted.
34 matches
Mail list logo
