Re: [HACKERS] Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1

On Wed, Nov 5, 2008 at 11:47 PM, Jaime Casanova <[EMAIL PROTECTED]> wrote: > On Fri, Oct 31, 2008 at 7:42 PM, Emmanuel Cecchet <[EMAIL PROTECTED]> wrote: >> Hi Nikhil, >> > > i'm looking at this one: > http://archives.postgresql.org/message-id/[EMAIL PRO

[HACKERS] where is the last hot standby patch?

i get lost with this one... i thought there were two patches that get merged into one, but i don't find nor the merged version nor the actualized version of any of one... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuado

Re: [HACKERS] Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1

; i review it on nov 6, and there were open questions by me and by Emmanuel none of those has been answered: http://archives.postgresql.org/pgsql-hackers/2008-11/msg00362.php -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuado

Re: [HACKERS] Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1

ce for a foreign key. > not directly, but you always can create a trigger instead of the foreign key constraint... mmm...the docs says that there is no good workaround, what about mention a trigger? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de

Re: [HACKERS] Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1

using CREATE TABLE because we are inventing new syntax but it seems like using ALTER TABLE is a *lot* of work altough ISTM more usefull -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1

On Thu, Nov 27, 2008 at 10:10 AM, Jaime Casanova <[EMAIL PROTECTED]> wrote: > On Thu, Nov 27, 2008 at 9:41 AM, Robert Haas <[EMAIL PROTECTED]> wrote: >> On Thu, Nov 27, 2008 at 8:31 AM, Gregory Stark <[EMAIL PROTECTED]> wrote: >>>> CREATE PARTITION t

Re: [HACKERS] Quick patch: Display sequence owner

y the table of course, but I'd > imagine to most people it'd just be noise. Could see it being shown in > the verbose version, \d+ foo.bar. > that's exactly why we want the aditional info... the idea of putting it on \d+ doesn't sounds too bad... to me at least... > For

Re: [HACKERS] Block-level CRC checks

On Thu, Nov 13, 2008 at 1:00 PM, Alvaro Herrera > This patch is also skipping pd_special and the unused area of the page. > v11 doesn't apply to cvs head anymore -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil -

Re: [HACKERS] rules regression test failed on mingw

On Mon, Dec 15, 2008 at 8:59 AM, Tom Lane wrote: > "Jaime Casanova" writes: >> i'm seeing a fail in the rules regression, seems like it is not >> ordering the results right even when the regression has an explicit >> order by... > > What locale is this

Re: [HACKERS] rules regression test failed on mingw

those rules? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] rules regression test failed on mingw

On Mon, Dec 15, 2008 at 10:26 AM, Alvaro Herrera wrote: > Tom Lane wrote: >> "Jaime Casanova" writes: >> > On Mon, Dec 15, 2008 at 8:59 AM, Tom Lane wrote: >> >> What locale is this running in? >> >> > Seems this is Spanish_Spain.1252 an

Re: [HACKERS] rules regression test failed on mingw

iour is correct in spain... we have a lot of spanish languages ;) administra...@casanova10 ~/pg.build/8.4dev $ bin/psql -a -f test.sql postgres select 'wieck'::text < 'wiech'::text; ?column? -- f (1 row) select 'wiech'::text < 'wieck'::

[HACKERS] rules regression test failed on mingw

more info -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 regression.diffs Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscrip

Re: [HACKERS] Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1

w partitions (inherit tables and modify the trigger)... and what i want to see is an automatic creation when it's needed... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-ha

Re: [HACKERS] Preventing index scans for non-recoverable index AMs

because makes those more slow without any benefit at all... now there will be one... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] Preventing index scans for non-recoverable index AMs

On Wed, Dec 17, 2008 at 5:54 PM, Simon Riggs wrote: > We don't yet have a mechanism for an > index AM to say "damn, this index is screwed up, don't use it". > mark pg_index.indisvalid and/or pg_index.indisready to false in the hot standby node? -- Atentame

Re: [HACKERS] Preventing index scans for non-recoverable index AMs

On Wed, Dec 17, 2008 at 5:47 PM, Kenneth Marshall wrote: > Rebuilding a hash index for the case > for which it is preferred (large, large tables) would be excrutiating. > there's such a situation? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y

Re: [HACKERS] rules regression test failed on mingw

gression-# select 'S2' union all select 's2' regression-# order by 1; ?column? -- s1 S1 s2 S2 (4 rows) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador

[HACKERS] about truncate

Hi, just out of curiosity, why TRUNCATE doesn't support ONLY? audit=# TRUNCATE only postgres_log; ERROR: syntax error at or near "only" LINE 1: TRUNCATE only postgres_log; -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guay

Re: [HACKERS] reloptions and toast tables

against the first) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [idea] a copied relkind in pg_attribute

ature optimization and that AFAIR is the root of all evil :) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To mak

Re: [HACKERS] parallel restore vs. windows

On Sun, Dec 14, 2008 at 12:13 PM, Andrew Dunstan wrote: > > This version completes properly on Windows with the regression database. > actually, this one doesn't apply cleanly on head -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrol

[HACKERS] hot standby on mingw

icolon at end of struct or union ../../../../src/include/access/xact.h:184: warning: type defaults to `int' in declaration of `xl_xact_abort_prepared' ../../../../src/include/access/xact.h:184: warning: data definition has no type or storage class make[4]: *** [heapam.o] Error 1 i gues

Re: [HACKERS] WIP: Automatic view update rules

om foo where id < 10 with check option; NOTICE: CREATE VIEW will create implicit INSERT/UPDATE/DELETE rules CREATE VIEW 3) one final point: seems like you'll have to update the rules regression test (attached the regression.diffs) -- Atentamente, Jaime Casanova Soporte y capacitación d

Re: [HACKERS] [idea] a copied relkind in pg_attribute

ld files is handled as a regular file suddenly, it can > make a confusion. It is a similar situation. > doesn't understand this... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hack

Re: [HACKERS] WIP: Automatic view update rules

issueing a warning. > yes. if we didn't do that we will be against spec. syntax rule 12 (again in 11.19 ) says: """ 12)If WITH CHECK OPTION is specified, then the viewed table shall be updatable. """ -- Atentamente, Jaime Casanova Sopor

Re: [HACKERS] TODO items for window functions

a very laizy or novice definition) but if that is correct or near correct maybe we need to follow the same pattern: create function -- without any decoration create aggregate maybe with a decoration of being window o create window aggregate or something similar... -- Atentamente, Jaime C

Re: [HACKERS] about truncate

late the child tables from the parent table, then you want to > remove all the rows from the parent table. > you're spying me? exactly that happen to me... ;) my first attempt was to execute TRUNCATE ONLY... and gives me an error and the thread begun... -- Atentamente, Jaime Casa

Re: [HACKERS] sum() over (partition by order) question

can be described better... don't know exactly if we can imitate this behaviour without window functions -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-

Re: [HACKERS] parallel restore

-Fc -v -m5 there is a way to know if it's really hanging or is simply too slow? i plan to let it run all night long just in case... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsq

Re: [HACKERS] parallel restore

On Tue, Jan 6, 2009 at 4:04 PM, Jaime Casanova wrote: > On Mon, Dec 29, 2008 at 6:42 PM, Andrew Dunstan wrote: >> >> Attached is the latest parallel restore patch. I think this is getting >> fairly close. >> > > hi, i was making some tests in windows... > any

Re: [HACKERS] parallel restore

On Tue, Jan 6, 2009 at 4:32 PM, Tom Lane wrote: > Andrew Dunstan writes: >> Jaime Casanova wrote: >>> i'm using: >>> pg_restore -f mic.backup -Fc -v -m5 > >> Strange. Maybe the server log will show activity? > > There's no connection info,

Re: [HACKERS] parallel restore

ne seems to be an optimization... maybe it's better to split in two incremental patches? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o

Re: [HACKERS] parallel restore

esn't understand you. Anyway i tried to run with --truncate-before-load and got a message about that should be necessary to run TRUNCATE CASCADE instead. Sorry, don't have the real message at hand. Seems like the recently applied patch about fseeko made this one to no longer apply cleanly -

Re: [HACKERS] Do we still need constraint_exclusion?

rd value at all? why we simply can't make the new 'partition' behaviour be the default for c_e on? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] New patch for Column-level privileges

d: 0002 ERROR: permission denied for relation t2 is this intended? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o

Re: [HACKERS] New patch for Column-level privileges

SELECT privileges when a JOIN is involved. One possible workaround is to create a view having just the desired columns and then grant privileges to that view. *** -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Gua

Re: [HACKERS] Recovery Test Framework

On Mon, Jan 12, 2009 at 12:20 PM, Joshua D. Drake wrote: > > IMO, the reasons to delay a release: > > Our grammar looks like MySQL > mmm... you mean if we add things like VALUES statement, lastval() and things like that? ;) -- Atentamente, Jaime Casanova Soporte y capacitació

Re: [HACKERS] New patch for Column-level privileges

just my preference. Please ask it official commiters/reviewers. > while i'm not an official commiter/reviewer, it seems natural to me to have an ExecGrant_Attribute() function. -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil -

Re: [HACKERS] Re: [GENERAL] Question regarding new windowing functions in 8.4devel

nk > FROM >foo >WINDOW w AS (partition by typ order by ts desc) > WHERE >foo_rank < 4; > > ERROR: syntax error at or near "WHERE" > LINE 8: WHERE >^ the WINDOW specification goes after the WHERE clause not before -- Atentamente,

Re: [HACKERS] New pg_dump patch, --no-stats flag, disables sending to statistics collector

organization that regularly dumps a database for backup purposes, but wants > to analyze only the application's database use. > i haven't looked at the patch nor it's functional use... but from the top of my head jumps a question: is there a reason to not make this the defa

Re: [HACKERS] WIP: Automatic view update rules

oblem with: * * ALTER TABLE ... ALTER COLUMN ... DROP NOT NULL; */ """ -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 regression.diffs Description: Binary data

Re: [HACKERS] Column-Level Privileges

LE examines permissions before locking the table > now; I don't think it ought to be grovelling through the columns without > lock. So this might be a place to leave well enough alone. > +1 -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrol

Re: [HACKERS] 8.5 release timetable, again

not sure how to compare the databases - execute 60 of the 121 tests (or at least those that create tables and insert/update/delete the most data) - crash the server and replay the WAL - execute the rest of the tests and cross your fingers :) -- Atentamente, Jaime Casanova Soporte y capacitación de Post

Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again

be scary if we start supporting every single piece of code MySQL accepts -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make cha

Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again

ken stuff... just because mysql users think is wonderful to not have to write sane code... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] remove flatfiles.c

d yes the planner is not very clever about partitioning and certainly that is something we need to fix not something we have to live with... no that that will be easy but hey! we have very brilliant people here (you being one of them) -- Atentamente, Jaime Casanova Soporte y capacitación de Post

[HACKERS] new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)

cts: > > PQconn *PQconnectParams(PQconninfoOption *params); > this sounds like a good idea, specially if we add new parameters to the conninfo string and want postgresql's client applications to use them. any one have a preference here? -- Atentamente, Jaime Casanova Soporte y capacitac

Re: [HACKERS] new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)

On Thu, Sep 10, 2009 at 12:01 AM, Jaime Casanova wrote: > On Mon, Jul 6, 2009 at 10:00 AM, Heikki > Linnakangas wrote: >> >> Could we >> have a version of PQconnectdb() with an API more suited for setting the >> params programmatically? The PQsetdbLogin() approach

Re: [HACKERS] new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)

On Mon, Sep 14, 2009 at 1:34 PM, Andrew Chernow wrote: > Jaime Casanova wrote: >> >> i extracted the functions to connect that Heikki put on psql in his >> patch for determining client_encoding from client locale and put it in >> libpq so i follow the PQconnectdb

Re: [HACKERS] new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)

On Mon, Sep 14, 2009 at 1:55 PM, Tom Lane wrote: > Jaime Casanova writes: >> i put the new function at the end of the exports.txt file, there's a >> reason to renumber the exports to put it at the beginning with the >> other PQconnectdb function? > > Exports.

Re: [HACKERS] new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)

On Mon, Sep 14, 2009 at 2:20 PM, Andrew Chernow wrote: > Jaime Casanova wrote: >> >> On Mon, Sep 14, 2009 at 1:34 PM, Andrew Chernow wrote: >>> >>> Jaime Casanova wrote: >>>> >>>> i extracted the functions to connect that Heikki put on ps

Re: [HACKERS] new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)

> Aahhh, correct you are Daniel son :) >>> >> >> ??? don't understand you ??? > > From the movie "karate kid"; oopps, should be Daniel San. > ah! got it... ;) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y

Re: [HACKERS] Logging configuration changes [REVIEW]

" > LOG:  Parameter "max_connections" cannot be changed without restarting the > server > LOG:  parameter "log_checkpoints" changed to "on" > ok, maybe this is not the most brilliant observation but someone has to say it... keep the same case in the word

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

y reason that server came to that situation was a horribly fsm configuration and a bad design that forces an incredible amount of updates... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent

Re: [HACKERS] [PATCH] Largeobject access controls

On Fri, Sep 18, 2009 at 8:29 PM, Stephen Frost wrote: > Jamie, > > How is the review for this coming?  Do you have any thoughts regarding > the new GUC? > Hi, sorry... these have been hard days... i'm just starting reviewing -- Atentamente, Jaime Casanova Soporte y capaci

Re: [HACKERS] [PATCH] Largeobject access controls

to put the GUC in the postgresql.conf file if you hope people know about it ;) it is not documented either About the code... - I don't like the name pg_largeobject_meta why not pg_largeobject_acl (put here any other name you like)? or there was a reason for that choose? -- Atentamente

Re: [HACKERS] [PATCH] Largeobject access controls

> has an identical structure to the current pg_largeobject). > > However, it seems to me the pg_largeobject_acl is an incorrect name, > because it also contains the owner identifier which is a part of metadata, > but not an acl. > have anyone better ideas about the

Re: [HACKERS] [PATCH] Largeobject access controls

On Tue, Sep 22, 2009 at 12:53 PM, Robert Haas wrote: > On Tue, Sep 22, 2009 at 1:29 PM, Jaime Casanova > wrote: >> have anyone better ideas about the name? if not, then go with >> pg_largeobject_meta > > I don't think there's anything wrong with calling it me

Re: [HACKERS] [PATCH] Largeobject access controls

functions but i think we can add them later if needed... > > Jaime Casanova wrote: >>> Do you think the "largeobject_compat_acl" is a meaningful name, instead? >> >> maybe something like "largeobject_security_controls"? > > It is important to conta

Re: [HACKERS] [PATCH] Largeobject access controls

ission denied for largeobject 16453      < dose not prevent > it i'm not really sure the warnings are worth the trouble but if you want to do it then the NOTICE version should use another message... i'm not comfortable with a "permission denied" that is simply ignor

Re: [HACKERS] [PATCH] Largeobject access controls

will mark the patch as "ready for committer" -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Lock Wait Statistics (next commitfest)

the patch itself: you haven't documented either. what is the pg_stat_lock_waits view for? and what are those fieldx it has? i'll let this patch as "needs review" for more people to comment on it... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría

Re: [HACKERS] Use "samehost" by default in pg_hba.conf?

l... to me the only reason it exists is to force me to change 'localhost' to '*' after installing, something i always do almost automaticaly =) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171

[HACKERS] moving system catalogs to another tablespace

? are there any reasons for this? i guess i still could this with symlinks, no? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] moving system catalogs to another tablespace

g00835.php seems like the original idea was to forbid this in all system catalogs except pg_largeobject, what happen then? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers ma

Re: [HACKERS] moving system catalogs to another tablespace

On Mon, Oct 5, 2009 at 10:26 PM, Tom Lane wrote: > Jaime Casanova writes: >> seems like the original idea was to forbid this in all system catalogs >> except pg_largeobject, what happen then? > > Nothing ... nobody got around to doing anything about it. > ah! well,

Re: [HACKERS] moving system catalogs to another tablespace

On Tue, Oct 6, 2009 at 9:43 AM, Alvaro Herrera wrote: > Jaime Casanova wrote: > >> now i think that what Euler shows me [1] is a fair compromise (this is >> to allow this only when in standalone mode with system catalogs >> allowed) otherwise we will have diferen

Re: [HACKERS] Writeable CTEs and side effects

sults... what the select reads from that results is another thing... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Writeable CTEs and side effects

On Wed, Oct 7, 2009 at 4:20 PM, Marko Tiikkaja wrote: > Jaime Casanova wrote: >> >> On Wed, Oct 7, 2009 at 4:08 PM, Marko Tiikkaja >> wrote: >>> >>> 1)      WITH t AS >>>       (UPDATE foo SET bar = bar+1 RETURNING *) >>>       SELECT

Re: [HACKERS] GRANT ON ALL IN schema

hat you need for every type of object here */ + + } i think this is more readable -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@post

Re: [HACKERS] GRANT ON ALL IN schema

On Mon, Oct 12, 2009 at 1:42 PM, Tom Lane wrote: > > ALTER DEFAULT PRIVILEGES ... GRANT ... ON TABLES TO ... > this makes sense to me, because you want the default to affect all new tables not only a new single table. so, as someone once told, +1 from me ;) -- Atentamente, Jaime

Re: [HACKERS] Client application name

On Tue, Oct 13, 2009 at 11:55 AM, Robert Haas wrote: > > What happens if we want to change the application name after the fact? >  Consider the case where there is a connection pooler between the > database and application, for example. > good point... -- Atentamente, Jaime Cas

Re: [HACKERS] Client application name

besides, as Robert mention, because of pooler connections using a GUC is more appropiate... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.

Re: [HACKERS] License clarification: BSD vs MIT

in the case both licenses are "roughly equivalent", because users are afraid of any changes. if we simply change our license for no good reason we will have a ton of questions about if PostgreSQL is being sold just as MySQL was... -- Atentamente, Jaime Casanova Soporte y capacitación de

Re: [HACKERS] License clarification: BSD vs MIT

On Mon, Oct 26, 2009 at 10:40 AM, Dave Page wrote: > On Mon, Oct 26, 2009 at 3:36 PM, Jaime Casanova > wrote: >> On Mon, Oct 26, 2009 at 8:08 AM, Simon Riggs wrote: >>> >>> ISTM we should apply to OSI for approval of our licence, so we can then >>>

Re: [HACKERS] Patch set under development to add usage reporting.

ughts on this. > There is still some hard work to be done.  We have an INFORMATION > SCHEMA implementation for MySQL 5.x, but not yet for PostgreSQL. > we have an information schema since 7.4 (http://www.postgresql.org/docs/7.4/static/information-schema.html) -- Atentamente, Jaime Casanova S

Re: [HACKERS] new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)

mportant enough please go for it -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.p

[HACKERS] total execution time as reported by auto_explain

:32:41 GMTLOG: duration: 779.938 ms plan: Sort (cost=1943.99..1967.38 rows=9355 width=466) (actual time=235.655..269.061 rows=4997 loops=1) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 2009-11

Re: [HACKERS] next CommitFest

that patch... and an email every week or every few days saying how many patches are, how many are being reviewed, how many hasn't been reviewed, and so on... then the remaining work should be not that much, no? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y d

Re: [HACKERS] next CommitFest

On Wed, Nov 11, 2009 at 4:40 PM, Robert Haas wrote: > On Wed, Nov 11, 2009 at 4:21 PM, Jaime Casanova > wrote: >> why we need a full time manager at all? >> why not simply use -rrreviewers to track the status of a patch? of >> course, we hope the author or reviewer

Re: [HACKERS] Syntax for partitioning

er some more explicit syntax for this not just reusing a table >      PARTITION name VALUES LESS THAN { range_upper | MAXVALUE } >    | PARTITION name VALUES IN ( list_value [,...] | DEFAULT ) > i remember someone making a comment about actually using operators instead of LESS THEN an

Re: [HACKERS] [PATCHES] 2WRS [WIP]

*/ > #ifdef TRACE_SORT > booltrace_sort = false; > #endif > - #ifdef DEBUG_BOUNDED_SORT > - booloptimize_bounded_sort = true; > - #endif it's seems you're removing something added in 8.3 -- regards, Jaime Casanova "Programming today is a race b

Re: [HACKERS] [PATCHES] Updatable views

even if it doesn't apply... just to see what needs to be done... -- regards, Jaime Casanova -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] column level privileges

On Tue, Apr 1, 2008 at 5:40 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote: > > Apologies if this gets duplicated - original seems to have been dropped due > to patch size - this time I am sending it gzipped. > just for the record, this patch doesn't apply cleanly to

Re: [HACKERS] Setting a pre-existing index as a primary key

T NULL constraints and a declared primary key ... so what > > did you really need it for? > > Agreed, functionally there's not much of a difference. It's more of a > matter of proper design identifying a primary key. > set right constraints it's good for documenting

Re: [HACKERS] proposal for smaller indexes on index-ordered tables

ot yet ensure that indexed tables remain indexed. > Just for the records. you mean *ordered* tables, don't you? Postgres does not yet ensure that ordered tables remain ordered. -- regards, Jaime Casanova Soporte y capacitación de PostgreSQL Guayaquil - Ecuador Cel. (593) 87171157

Re: [HACKERS] CommitFest rules

age. Does that > sound right? > yeah! that was always the process... email to -hackers the proposal, design, discussion, etc... email to -patches the patch itself... the only change is that we are no longer using -patches for this but the commitfest page. -- regards, Jaime Casanova Soporte

Re: [HACKERS] [PATCHES] Extending grant insert on tables to sequences

On 7/8/08, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > Jaime Casanova escribió: > > On Thu, May 22, 2008 at 1:18 PM, Jaime Casanova <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > The idea of this patch is to avoid the need to make explicit grants

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

ycle well this patch originally appears. but i have no time in this moment to confirm that -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

to change it for the view at least not without manually create a new DO INSTEAD rule (something i don't like)... i'm missing something? or can we implement such "REDIRECT" with the ability to respect view's own defaults? -- Atentamente, Jaime Casanova Soporte y capacitac

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

[...] > > We could imagine attaching a "no auto rules please" property to views > (hm, perhaps this is an application for reloptions for a view). > +1 for reloptions (the other way i think is to invent new syntax and i think the reloptions are exactly to avoid that) -

Re: 8.4 release planning (was Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules)

ust like someone suggests) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

; reloption would have to try to add or get rid of. why we don't follow this path from the beggining? what are the pros and cons of this? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

pdatable the view is updatable -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.4 release planning

ys during the critical integration phase .. > which means we haven't really had 3 months of integration, we've had *two*. > +1 -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via p

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

gt; aggregates? Do we throw a warning? > yes. we detect that and send a warning saying that there not be any rules -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers ma

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

spec... having said that, i don't think that inventing new syntax is the way to go... a reloption seems better (thinking a little more, it could be a problem if the user changes the reloptions of an already created view) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesorí

Re: [HACKERS] 8.4 release planning

the next release should be in 6 months... we release at least 6 months later... ATM that a new release cycle starts new patch will arrive and there will be no way to get the shorted release in time... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de

Re: [HACKERS] [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle

>> could work, though. > > Yeah, I tend to prefer the GUC approach over nonstandard syntax too. > We'd need a GUC anyway to determine the default behavior if no > nonstandard clause appeared; so we might as well just do that and not > bother with the syntax options. >

<    1   2   3   4   5   6   7   8   9   >