On 06/18/2013 01:52 AM, Jeremy Evans wrote:
Maybe I am misunderstanding how LATERAL is supposed to work, but my
expectation is that doing a LEFT JOIN should not remove rows from
the LHS.
I have added this to the list of 9.3 blockers.
https://wiki.postgresql.org/wiki/PostgreSQL_9.3_Open_Items
Maybe I am misunderstanding how LATERAL is supposed to work, but my
expectation is that doing a LEFT JOIN should not remove rows from
the LHS. I would expect all of the following select queries would
return a single row, but that isn't the case:
CREATE TABLE i (n integer);
CREATE TABLE j (n
On 06/18/2013 01:52 AM, Jeremy Evans wrote:
Maybe I am misunderstanding how LATERAL is supposed to work, but my
expectation is that doing a LEFT JOIN should not remove rows from
the LHS. I would expect all of the following select queries would
return a single row, but that isn't the case:
Bruce Momjian wrote:
Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Does anyone know why so many LEFT JOINs are used in psql/describe.c to
join to the pg_namespace table, like here:
Yes, pg_relnamespace is definitely not null. I've actually already removed
the left
On Tue, 10 May 2005, Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Does anyone know why so many LEFT JOINs are used in psql/describe.c to
join to the pg_namespace table, like here:
Yes, pg_relnamespace is definitely not null. I've actually
Marc G. Fournier wrote:
On Tue, 10 May 2005, Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Does anyone know why so many LEFT JOINs are used in psql/describe.c to
join to the pg_namespace table, like here:
Yes,
Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Does anyone know why so many LEFT JOINs are used in psql/describe.c to
join to the pg_namespace table, like here:
Yes, pg_relnamespace is definitely not null. I've actually already removed
the left joins from my \df patch,
Does anyone know why so many LEFT JOINs are used in psql/describe.c to
join to the pg_namespace table, like here:
printfPQExpBuffer(buf,
SELECT c.oid,\n
n.nspname,\n
c.relname\n
FROM pg_catalog.pg_class c\n
LEFT JOIN pg_catalog.pg_namespace n ON n.oid =
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Does anyone know why so many LEFT JOINs are used in psql/describe.c to
join to the pg_namespace table, like here:
I thought a pg_class row always pointed to a valid pg_namespace row
because of our dependency restrictions.
Yes, pg_relnamespace
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Does anyone know why so many LEFT JOINs are used in psql/describe.c to
join to the pg_namespace table, like here:
Yes, pg_relnamespace is definitely not null. I've actually already removed
the left joins from my \df patch, since I had to rewrite
Morning ...
I'm trying to wrack my brain over something here, and no matter
how I try and look at it, I'm drawing a blank ...
I have two tables that are dependent on each other:
notes (86736 tuples) and note_links (173473 tuples)
The relationship is that one
Tom Lane writes:
$PSQL -d template1 -At -F ' ' \
-c "SELECT datname, usename, pg_encoding_to_char(d.encoding),
datistemplate, datpath FROM pg_database d LEFT JOIN pg_shadow u ON (datdba
= usesysid) WHERE datallowconn;" | \
while read DATABASE DBOWNER ENCODING ISTEMPLATE DBPATH; do
Peter Eisentraut [EMAIL PROTECTED] writes:
Is there a more robust way of reading the data into the script?
Provided that 'cut' is portable, then this works for me:
My old copy of Horton's _Portable C Software_ says that cut(1) is a
SysV-ism adopted by POSIX. At that time (1990) it wasn't
Tom Lane writes:
If you think depending on POSIX utilities is OK, then use cut.
I'd recommend sed, though.
This has gotten pretty silly:
TAB=' ' # tab here
$PSQL -d template1 -At -F "$TAB" \
-c "SELECT datname, usename, pg_encoding_to_char(d.encoding),
datistemplate, datpath, 'x' FROM
Peter Eisentraut [EMAIL PROTECTED] writes:
I'm not sure whether this is actually an overall improvement. I'm tempted
to just coalesce(usename, {some default user}) instead.
I thought about that to begin with, but figured you wouldn't like it ;-)
regards, tom lane
Peter Eisentraut [EMAIL PROTECTED] writes:
This snippet in pg_dumpall
$PSQL -d template1 -At -F ' ' \
-c "SELECT datname, usename, pg_encoding_to_char(d.encoding),
datistemplate, datpath FROM pg_database d LEFT JOIN pg_shadow u ON (datdba
= usesysid) WHERE datallowconn;" | \
while read
hi, there!
test=# create table a(id int primary key);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'a_pkey' for
table 'a'
CREATE
test=# create table b(id int references a);
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY
check(s)
CREATE
test=# insert into a
17 matches
Mail list logo
