Hi,
Just something I noticed to 'simply work':
db=# select avg(pg_catalog. pg_stats . avg_width) from pg_stats;
avg
-
10.6654945054945055
(1 row)
It seems that all whitespace between schema/table/field references is ignored?
Not saying this is a bad thi
L.S.
I noticed the following and wondered whether this is intentional or an
oversight in pg_dump's '-c' option?
The clean option causes the public schema to be dropped and recreated, but
this is done with the default schema priviliges, which are not the same as the
ones assigned during create
Hi Adrian,
Op zaterdag 11 februari 2017 13:02:29 schreef Adrian Klaver:
> What version of Postgres?
Ah, sorry, missed copying that in:
postgres=# select version();
version
-
Hi Adrian,
Op zaterdag 11 februari 2017 13:31:17 schreef Adrian Klaver:
> I see the same thing now.
Glad you do ;)
> That seems to cause a problem
Yeah, I originally ran into this when I noticed that on a restored db a
regular user lost access to tables created by him in the public schema.
G
Hi Tom/Stephen/Adrian,
Op zaterdag 11 februari 2017 15:28:55 schreef Tom Lane:
> I'm inclined to argue that it was a mistake to include any non-pinned
> objects in pg_init_privs.
> We might need to fix pg_dump too, but I think these entries in
> pg_init_privs should simply not be there.
Thanks f
Hi Stephen,
Op maandag 13 februari 2017 09:10:42 schreef Stephen Frost:
> We should be able to get it addressed shortly.
Great, 'as always', I'd like to add!
Thanks for the great work, people. This cannot be stated too often...
> For your specific case
Thanks for the additional info, interesti
L.S.
# select version();
version
---
PostgreSQL 8.4.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC)
4.4.4, 64-bit
(1 row)
Hi Tom,
Op maandag 18 april 2011, schreef Tom Lane:
> Hmmm look into pg_shdepend to see if there are entries linking
> those functions to an owner.
mmm, indeed it seems that some things are our of sync here
the following is coming from the production database, thus after the 'reassign
from
Hi,
Op woensdag 20 april 2011, schreef Tom Lane:
> I wonder whether the pg_shdepend data is actually wrong, or just the
> indexes on it are at fault. Did you try forcing that query to be done
> with a seqscan
Just did by setting enable_indexscan to false and verifying that all is used
are seq_s
Hi,
Op woensdag 20 april 2011, schreef Tom Lane:
> Actually, now that I think about it, 8.4 didn't allow on-the-fly
> reindexing of shared catalogs anyway. So that couldn't be your problem
> even if the test had shown the indexes didn't match the catalog. But
> it seems the rows actually disappe
Hi,
This doesn't seem to make sense to me, can someone explain the rationale
behind it?
postgres=# select version();
version
---
PostgreSQL 8.4.4 on x86_64-unknown-linux-
Hi Tom,
> The rationale is "do what the SQL spec says" ;-)
can't argue with the standard ;)
> I seem to recall a previous discussion in the PG lists
Good memory !
Adding 'sql standard' to the search options helped, this issue seems to elude
people every now and then, given (amongst others):
L.S.
Could someone point me to the formal reason why in:
postgres=# select version();
version
---
PostgreSQL 9.0.4 on x86_64-unknow
Hi Tom,
> ANY(SELECT ...) normally means searching down the rows
ah, yeah, but I was focussing here more on the ANY() from documentation
paragraph 9.21.3 (postgresql v9.1.1):
expression operator ANY (array expression)
> where the select is expected to return a single column matching th
L.S.
I have a database created on:
db=# select version();
version
-
PostgreSQL 8.0.1 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66
(1 row)
The initdb was done using no-locale and unicode as
Hi Tatsuo / Tom,
[TI]
> Apparently your hack does not kill #define USE_WIDE_UPPER_LOWER.
Mmm, I think it does, but mind you, the hack was applied to the first machine
only (since that was the one with the 'original' buggy glibc causing a
postmaster crash when using upper() and stuff), while it
> > I've made a PL/pgSQL function to validate UPC and EAN barcodes.
> > It works correctly, but is a little ugly.
> > Wondering if any PL/pgSQL experts can offer some suggestions. (I'm
> > new to PL/pgSQL.)
For what it's worth, here's a function I'm using to calculate the checksum of
an EAN barc
L.S.
I noticed the following :
Workstation used to build RC1:
2.4.21-260-athlon, i686 athlon i386 GNU/Linux
Configured with :
./configure
--enable-thread-safety
--disable-shared
--prefix=/usr/src/postgresql/install
> What do you show for PTHREAD_* in Makefile.global?
PTHREAD_CFLAGS = -pthread -D_REENTRANT -D_THREAD_SAFE
-D_POSIX_PTHREAD_SEMANTICS
PTHREAD_LIBS= -lpthread
> Is this another platform where the library doesn't remember dependencies
> used when it was built? It is Linux
I just confirmed that the same goes for:
Linux 2.6.5-7.111.5-default, i686 i686 i386 GNU/Linux
(SuSE v9.1)
Makefile.global holds:
PTHREAD_CFLAGS = -pthread -D_REENTRANT -D_THREAD_SAFE
-D_POSIX_PTHREAD_SEMANTICS
PTHREAD_LIBS= -lpthread
Would you like confirmation for
L.S.
I'd like to prevent updates on a specific field when done during regular use
or during the execution of any non-deferred trigger, while allowing them when
done from deferred triggers. (BTW, we're talking version 8.1 here).
Currently there doesn't seem to be a way to know whether code is e
> >> Ratio: when deferred triggers on table A are used to calculate field
> >> values of table B (which then obviously need an update), one might want
> >> to prevent direct updates on these fields of table B
[BW III]
> It might also work for you to do this with access rights.
Well, actually that
> After reading the explanation, this seems way too specialized a
> situation to make a good argument that we need a general feature
> of the sort.
Ok, however, thanks for your time on it, anyway!
> You can get to where you need to be by passing an indicator in
> the trigger arguments
Argh, it's
Hi,
I may be overlooking some option here, but somewhere between the v7 series and
the current v8.1.1 that I'm using, failed queries stopped being logged, only
the error message appears in the log (config option log_statement = all).
I.e. executing
select 1 2;
will result in just the
L.S.
Sorry 'bout that last post in dutch, it was meant to go to a private
address.
--
Best,
Frank.
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
L.S.
I was afraid something like this would happen ;)
Just to be clear on the matter, the wrong post was just part of a conversation
between the OP and I. We are not exactly strangers and there was no
intentional nor accidential bad advice intended ;)
For the record I'll repeat on the list tha
Hi,
I'm using a 9500 line script to create an initial database. After applying a
number of changes, I was repeatedly executing this script while hunting for
typos. The script itself takes care of dropping the various objects and every
now and then (when delta t << autovacuum t) a manual vacuum
> I'm sorry, I meant to say save a copy of
> pg_attribute_relid_attnum_index. The correct filename for it can be
> found via
> select relfilenode from pg_class where relname =
> 'pg_attribute_relid_attnum_index';
Got it, made a backup of the entire database as well. Since the db wasn't
filled ye
Some additional info:
# select * from pg_class where relname = 'article_property_tree';
-[ RECORD 1 ]--
+---
relname| article_property_tree
relnamespace | 2200
reltype| 8349772
relowner | 1000
relam |
Hi all,
Boiling down a problem in one of my queries, I noticed this behaviour.
# select version();
version
PostgreSQL 7.4.2 on i586-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3
(1 row)
#
> > I'm wondering about the reason this cast to text takes place,
>
> UNION requires assignment of a definite type to the inputs, because
> otherwise there's no certainty that we know how to identify distinct
> and non-distinct values. The alternative to assigning TEXT is to
> reject the inner UNI
L.S.
Either the docs or I are missing something
While using libpq I noticed that listen/notify calls were being converted to
lowercase. A further look showed that the listen/notify calls seem to be
totally case insensitive:
free4testing=# select version();
ve
> > If during a transaction a number of deferred triggers are fired, what
> > will be their execution order upon the commit?
> Should be alphabetical within each triggering event, IIRC.
Mmm, yes, but are all the deferred triggers on the same event 'grouped'?
What I'm thinking about is something
> > Any execution order for regular triggers would be as good as any other
> This is perhaps true for "cleanly designed" applications, but people
> have requested that we nail down the execution order, and we have
> responded by specifying that it's alphabetical within an event.
I understand and a
Hi,
The following works :
db=# select 1 = ANY ('{1,2,3}'::int[]);
?column?
--
t
(1 row)
This doesn't :
db=# select 1 = ANY (select '{1,2,3}'::int[]);
ERROR: operator does not exist: integer = integer[]
HINT: No operator matches the given name and argument type(s). You may need
to
> > works =# select 1 = ANY ('{1,2,3}'::int[]);
> > doesn't work =# select 1 = ANY (select '{1,2,3}'::int[]);
> > works =# select 1 = ANY ((select '{1,2,3}'::int[])::int[]);
I may be misinterpreting your reply but.
My real-world application has a set-returning PL/pgSQL function for which I
c
Hi,
Not exactly a showstopper, but I noticed this behaviour:
db=# create table f1 (id int, value int);
CREATE TABLE
db=# insert into f1 select 1 as id, null;
INSERT 25456306 1
db=# insert into f1 select distinct 2 as id, null;
ERROR: column "value" is of type integer but expression is of type
Hi Tom,
> No, because it never had any: NULL is typeless (type UNKNOWN, to the
> parser). But to do a DISTINCT, the parser has to assign datatypes to all the
> columns (to determine the comparison rules). The default assumption for an
> UNKNOWN constant is type TEXT.
I grok, thanks for the quick
> This is a psql artifact, not a feature supported by the backend.
> If you want to do likewise, emulate the code in src/bin/psql/large_obj.c.
Thanks, it seems that since I also want to allow non-superusers as well to
'trigger' an automagically created comment on a large object 'upload', it was
Hi,
FWIW, I walked into this one when changing an int[ ] into a numeric(5,1)[ ] :
IF ( 0::int ) => interpreted as false
IF ( 0.0::numeric(5,1) ) => interpreted as true
Yes, there should have been used some expression that evaluated to a boolean
to begin with, but 'if (int)' is not all that u
st being inquisitive, I understand there's a whole lot of items on the
list that are a tad more important to fix ;-)
--
Best,
Frank van Vugt.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
41 matches
Mail list logo
