Sophie Yang wrote:
I am trying to implement a PL/PgSQL function as following:
CREATE OR REPLACE FUNCTION sort_by_d_idx (nids INT[][], tbl_name VARCHAR)
RETURNS varchar[]
AS $$
DECLARE
result varchar[];
BEGIN
EXECUTE 'SELECT ARRAY(SELECT t.idx FROM generate_series(array_lower($1,1),
array_up
On Thursday 05 March 2009 12:31:17 Heikki Linnakangas wrote:
> Xavier Bugaud wrote:
> > This trivial patch allows PostgreSQL to understand the MUST (Mauritius
> > Summer Time) time zone that is in used since 2008-11.
> >
> > ...
> >
> > *** src/timezone/tznames/Default1 May 2008 20:05:08 -0
Hi,
I am trying to implement a PL/PgSQL function as following:
CREATE OR REPLACE FUNCTION sort_by_d_idx (nids INT[][], tbl_name VARCHAR)
RETURNS varchar[]
AS $$
DECLARE
result varchar[];
BEGIN
EXECUTE 'SELECT ARRAY(SELECT t.idx FROM generate_series(array_lower($1,1),
array_upper($1,1)) AS s
Stephen,
The attached patch fixes the matter.
It fixes up attribute number of child relation when it is extracted.
(*) Injected elog()s are removed.
postgres=# select * from t1;
NOTICE: markRTEForSelectPriv: ACL_SELECT on t1.a
NOTICE: markRTEForSelectPriv: ACL_SELECT on t1.c
NOTICE: ExecCheck
Xavier Bugaud wrote:
This trivial patch allows PostgreSQL to understand the MUST (Mauritius Summer
Time) time zone that is in used since 2008-11.
...
*** src/timezone/tznames/Default1 May 2008 20:05:08 - 1.6
--- src/timezone/tznames/Default5 Mar 2009 07:03:19 -
**
KaiGai Kohei wrote:
The other one is it has two kind of reader permissions ("select" and
"use").
The "select" permission is applied when user tries to read tables/columns
and its contents are returned to the user.
The "use" permission is applied when user tries to read table/columns,
but its con
Hi,
This trivial patch allows PostgreSQL to understand the MUST (Mauritius Summer
Time) time zone that is in used since 2008-11.
Before the patch :
# SELECT '2009-03-15 14:54:15 MUST'::timestamp;
ERROR: invalid input syntax for type timestamp: "2009-03-15 14:54:15 MUST"
After the patch :
# SEL
KaiGai Kohei wrote:
> I've observed the behavior of column-level privileges and
> required permissions with a few elog()s injected.
>
> I noticed rte->selectedCols is incorrect when we make a query
> on inherited tables.
>
> See below:
> -
> postgre
I've observed the behavior of column-level privileges and
required permissions with a few elog()s injected.
I noticed rte->selectedCols is incorrect when we make a query
on inherited tables.
See below:
-
postgres=# CREATE TABLE t1 (a int, b int, c i
* Robert Haas (robertmh...@gmail.com) wrote:
> Like everyone else who has responded to this thread, I think this is a
> pretty terrible idea.
[...]
+1 on Robert's assessment from me. I'm generally a huge fan of doing
the right thing, but as my boss often likes to point out, you need to
pick your
On Wed, 4 Mar 2009, Joshua D. Drake wrote:
Something that continues to grind my teeth about our software is that we
are horribly inconsistent with our system catalogs.
I'd suggest staring at the gyrations required to do an in-place upgrade,
then considering how the changes you're suggesting w
On Wed, Mar 4, 2009 at 3:32 PM, Joshua D. Drake wrote:
> Something that continues to grind my teeth about our software is that we
> are horribly inconsistent with our system catalogs. Now I am fully and
> 100% aware that changing this will break things in user land but I want
> to do it anyway. In
> "Tom" == Tom Lane writes:
> Magnus Hagander writes:
>> I think this sounds a lot like another request for a set of system
>> views with nicer names.
Tom> What's the state of the newsysviews project, anyway? I don't
Tom> recall hearing much about it lately.
At the time it was propos
Heikki, Thanks for your comments.
Heikki Linnakangas wrote:
Ok, I've taken a quick look at this too. My first impression is that
this is actually not a very big patch. Much much smaller than I was
afraid of. It seems that dropping the row-level security and the other
change you've already done
Appreciate for your kind help!
2009/3/3 Fujii Masao :
> On Tue, Mar 3, 2009 at 1:47 PM, Fujii Masao wrote:
>> Hi Suzuki-san,
>>
>> On Thu, Feb 26, 2009 at 5:03 AM, Koichi Suzuki wrote:
>>> My reply to Gregory's comment didn't have any objections. I believe,
>>> as I posted to Wiki page, latest
2009/3/4 André Volpato :
> I´m trying to install postgres 8.3.6 at AIX 5.3, and I got a declaration
> error that I presume its related to this [1] thread.
>
> Here´s some info:
> - Bladecenter IBM JS22 - PowerPC_POWER6 quad 4GHZ 64 bits
> - AIX 5.3.0
> - Postgresql 8.3.6
> - gcc version 4.2.0
> - G
On Mar 4, 2009, at 6:07 PM, Josh Berkus wrote:
Andrew,
Back on that track, I'd like to see a facility whereby we could
provide an alias (or synonym, to use a nearby subject) columns and
other objects. That would help to overcome naming glitches without
breaking things quite so much.
Be
Kevin Grittner wrote:
Josh Berkus wrote:
You could always take a survey ... bosses love surveys ...
Done: http://wwwmaster.postgresql.org/community/
Is there some assumed relationship between those options and whether
they'd like to see the names changed?
Also, it's hard to pick what opti
Andrew,
Back on that track, I'd like to see a facility whereby we could provide
an alias (or synonym, to use a nearby subject) columns and other
objects. That would help to overcome naming glitches without breaking
things quite so much.
Believe it or not, a large PostgreSQL user in LA just b
>>> Josh Berkus wrote:
>> You could always take a survey ... bosses love surveys ...
>
> Done: http://wwwmaster.postgresql.org/community/
Is there some assumed relationship between those options and whether
they'd like to see the names changed?
Also, it's hard to pick what option to choose t
>>> Andrew Dunstan wrote:
> Back on that track, I'd like to see a facility whereby we could
provide
> an alias (or synonym, to use a nearby subject) columns and other
> objects. That would help to overcome naming glitches without breaking
> things quite so much.
How is that different from wh
Josh Berkus wrote:
Well, honestly, this was one of the reasons why AndrewSN, David and I
... and Elein ...
pushed NewSysViews. Non-hackers really shouldn't be accessing the
system catalogs directly, and if information_schema doesn't give them
enough data, we should start adding new views
Bill,
You could always take a survey ... bosses love surveys ...
Done: http://wwwmaster.postgresql.org/community/
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Well, honestly, this was one of the reasons why AndrewSN, David and I
... and Elein ...
pushed NewSysViews. Non-hackers really shouldn't be accessing the
system catalogs directly, and if information_schema doesn't give them
enough data, we should start adding new views to I_S.
--
Sent v
On Wed, Mar 4, 2009 at 9:34 AM, Joshua Tolley wrote:
> Way back in this thread[1] one of the arguments against allowing
> some version of CREATE SYNONYM was that we couldn't create a synonym for
> an object in a remote database. Will the SQL/MED work make this sort of
> thing a possibility? I rea
Tom Lane wrote:
Magnus Hagander writes:
I think this sounds a lot like another request for a set of system views
with nicer names.
What's the state of the newsysviews project, anyway? I don't recall
hearing much about it lately.
Final verdict was that we need to make it integrate better wi
Joshua D. Drake wrote:
Hello,
Something that continues to grind my teeth about our software is that we
are horribly inconsistent with our system catalogs. Now I am fully and
100% aware that changing this will break things in user land but I want
to do it anyway. In order to do that I believe we
Magnus Hagander writes:
> I think this sounds a lot like another request for a set of system views
> with nicer names.
What's the state of the newsysviews project, anyway? I don't recall
hearing much about it lately.
regards, tom lane
--
Sent via pgsql-hackers mailing
>>> "Joshua D. Drake" wrote:
> It would lower the cost (intellectually as well as dollars) of
> development and administration for every single user of the
> database.
-1
Any savings couldn't possibly pay for the cost and pain of this, at
least in our shop.
> I can't count how many times I
Joshua D. Drake wrote:
> On Wed, 2009-03-04 at 21:27 +, Dave Page wrote:
>> On Wed, Mar 4, 2009 at 9:23 PM, Joshua D. Drake
>> wrote:
>>
>>> It is not easy to say. It is correct to say. I am under no illusion that
>>> this will not be painful. As far as "man weeks of recoding". Sorry, I
>>> k
=?ISO-8859-1?Q?Andr=E9_Volpato?= writes:
> First I tryed to configure with no options, and then make throw this:
> float.c:74: error: static declaration of 'cbrt' follows non-static declaration
> After some googling, I find Bruce´s path back on 7.4, that removed my_cbrt
> trick.
> So, I change
On Wed, 2009-03-04 at 16:28 -0500, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > Something that continues to grind my teeth about our software is that we
> > are horribly inconsistent with our system catalogs. Now I am fully and
> > 100% aware that changing this will break things in user land bu
On Wed, 2009-03-04 at 21:27 +, Dave Page wrote:
> On Wed, Mar 4, 2009 at 9:23 PM, Joshua D. Drake
> wrote:
>
> > It is not easy to say. It is correct to say. I am under no illusion that
> > this will not be painful. As far as "man weeks of recoding". Sorry, I
> > know that will be tough.
>
On Wed, Mar 4, 2009 at 9:24 PM, Bill Moran wrote:
> In response to Dave Page :
>
> Don't those folks have to tweak their code with each new release anyway?
> Because those tables are constantly changing? I know we hit problems
> with the way triggers are stored in 8.3 compared to earlier versions
"Joshua D. Drake" writes:
> Something that continues to grind my teeth about our software is that we
> are horribly inconsistent with our system catalogs. Now I am fully and
> 100% aware that changing this will break things in user land but I want
> to do it anyway. In order to do that I believe w
On Wed, Mar 4, 2009 at 9:23 PM, Joshua D. Drake wrote:
> It is not easy to say. It is correct to say. I am under no illusion that
> this will not be painful. As far as "man weeks of recoding". Sorry, I
> know that will be tough.
It'll be a complete and utter waste of time, and make a horrible me
In response to Dave Page :
> On Wed, Mar 4, 2009 at 9:09 PM, Joshua D. Drake
> wrote:
>
> >> I assume you'll be putting in the weeks/months of work required to fix
> >> pgAdmin & phpPgAdmin which would be far better spent on new features
> >> than uglifying the code in far nastier ways than the
On Wed, 2009-03-04 at 21:14 +, Dave Page wrote:
> On Wed, Mar 4, 2009 at 9:09 PM, Joshua D. Drake
> wrote:
> > *Shrug* long term consistency is the better choice.
>
> Easy to say if you're not one of the people for whom such a change
> would mean weeks of recoding, the need to start QA'ing
On Wed, Mar 4, 2009 at 9:09 PM, Joshua D. Drake wrote:
>> I assume you'll be putting in the weeks/months of work required to fix
>> pgAdmin & phpPgAdmin which would be far better spent on new features
>> than uglifying the code in far nastier ways than the current state of
>> the catalogs?
>
> *S
On Wed, 2009-03-04 at 21:01 +, Dave Page wrote:
> On Wed, Mar 4, 2009 at 8:32 PM, Joshua D. Drake
> wrote:
> > Hello,
> >
> > Something that continues to grind my teeth about our software is that we
> > are horribly inconsistent with our system catalogs. Now I am fully and
> > 100% aware that
On Wed, 2009-03-04 at 15:50 -0500, Andrew Dunstan wrote:
> > It seems to me that the best method would be to follow the
> > information_schema naming conventions as information_schema is standard
> > compliant (right?).
> >
> > Thoughts?
> >
>
>
> What would be the benefit? Apart from satisfy
On Wed, Mar 4, 2009 at 8:32 PM, Joshua D. Drake wrote:
> Hello,
>
> Something that continues to grind my teeth about our software is that we
> are horribly inconsistent with our system catalogs. Now I am fully and
> 100% aware that changing this will break things in user land but I want
> to do it
Joshua D. Drake wrote:
Hello,
Something that continues to grind my teeth about our software is that we
are horribly inconsistent with our system catalogs. Now I am fully and
100% aware that changing this will break things in user land but I want
to do it anyway. In order to do that I believe w
Hi,
André Volpato schrieb:
I´m trying to install postgres 8.3.6 at AIX 5.3, and I got a declaration
error that I presume its related to this [1] thread.
[...]
After some googling, I find Bruce´s path back on 7.4, that removed
my_cbrt trick. So, I changed float.c to the old code (the whole
HAV
I´m trying to install postgres 8.3.6 at AIX 5.3, and I got a declaration
error that I presume its related to this [1] thread.
Here´s some info:
- Bladecenter IBM JS22 - PowerPC_POWER6 quad 4GHZ 64 bits
- AIX 5.3.0
- Postgresql 8.3.6
- gcc version 4.2.0
- GNU Make 3.80
First I tryed to configure
On Wed, Mar 04, 2009 at 03:15:23PM -0500, Tom Lane wrote:
> Joshua Tolley writes:
> > I didn't mean to suggest that SQL/MED on its own could be used to make
> > SYNONYMs, but rather that given SQL/MED, perhaps we could reconsider
> > some sort of CREATE SYNONYM functionality to go along with it. A
> Use plain oids or regclass values, not a text column, if you are trying
> to store table identities.
>
wouldn`t oids change on dump/reload?
Greetings
Marcin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
Hello,
Something that continues to grind my teeth about our software is that we
are horribly inconsistent with our system catalogs. Now I am fully and
100% aware that changing this will break things in user land but I want
to do it anyway. In order to do that I believe we need to come up with a
ve
> -Original Message-
> From: Dimitri Fontaine [mailto:dfonta...@hi-media.com]
> Sent: Wednesday, March 04, 2009 12:28 PM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Is there an official log reader for PostgreSQL?
>
> Hi,
>
> Le 4 mars 09 à 21:17, Dann Cor
marcin mank wrote:
Use plain oids or regclass values, not a text column, if you are trying
to store table identities.
wouldn`t oids change on dump/reload?
I don't know. I'd also be interested to know if there is a difference if
we use pg_restore with a binary format or sql dump, or if t
Hi,
Le 4 mars 09 à 21:17, Dann Corbit a écrit :
I am interested in doing a near real time transaction processor. If
there is a place to find the specification for the log reader, I would
be keen to know it.
Have you read about PGQ yet? Some links include:
http://www.pgcon.org/2008/schedule
Ok, I've taken a quick look at this too. My first impression is that
this is actually not a very big patch. Much much smaller than I was
afraid of. It seems that dropping the row-level security and the other
change you've already done have helped a great deal.
My first question is, why does th
The GIN_EXTRACT_VALUE macro returns a pointer to a static 'entries'
variable. That doesn't seem safe. Is it really never possible to have to
two GIN searches in a plan, both calling and using the value returned
by extractValue simultaneously? In any case that seems like a pretty
weak assumptio
On Wednesday 04 March 2009 16:34:54 Joshua Tolley wrote:
> Way back in this thread[1] one of the arguments against allowing
> some version of CREATE SYNONYM was that we couldn't create a synonym for
> an object in a remote database. Will the SQL/MED work make this sort of
> thing a possibility?
Th
I am interested in doing a near real time transaction processor. If
there is a place to find the specification for the log reader, I would
be keen to know it.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
Joshua Tolley writes:
> I didn't mean to suggest that SQL/MED on its own could be used to make
> SYNONYMs, but rather that given SQL/MED, perhaps we could reconsider
> some sort of CREATE SYNONYM functionality to go along with it. A major
> argument against CREATE SYNONYM in the past was that we w
On Wed, Mar 04, 2009 at 10:14:41AM -0500, Jonah H. Harris wrote:
>SQL/MED does support foreign tables, which are basically synonyms for
>remote tables. Other than that, it has no real similarity to synonym
>behavior for other database objects such as views, functions, or local
>tab
On Wed, Mar 04, 2009 at 03:26:36PM +0200, Peter Eisentraut wrote:
> Martin Pihlak wrote:
>> Proposal attached. This adds two C functions:
>>
>> List *GetForeignConnectionOptions(Oid serverid, Oid userid);
>> char *GetForeignConnectionString(Oid serverid, Oid userid);
>>
>> One for obtaining all of
Alvaro Herrera writes:
>> Seems doable.
> Attached.
The TWO_MEMBER_SCANKEYWORD business seems a bit dangerous --- if the
header file is read without having #defined that correctly, bad things
will happen. It might be better to leave that out, always define the
struct the same, and just have pg_
Peter Eisentraut writes:
> I think the proper way to handle it might be to introduce a new
> privilege type -- call it SELECT if you like -- that determines
> specifically whether you can *see* the options of a foreign-data
> wrapper, foreign server, or user mapping, respectively. As opposed t
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Tom Lane wrote:
>
> > > What I'd suggest is something similar to the design of the errcodes.h
> > > header: create a header file containing just the list of PG_KEYWORD
> > > macro calls, and have the different users #include it after defining
> > >
Alvaro Herrera wrote:
> Tom Lane wrote:
> > What I'd suggest is something similar to the design of the errcodes.h
> > header: create a header file containing just the list of PG_KEYWORD
> > macro calls, and have the different users #include it after defining
> > that macro appropriately. Having .
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
>> /*
>> + * We don't want to include the gram.h file on frontend builds, except
>> ECPG, so
>> + * leave out the second struct member in that case.
>> + */
>> + #if !defined FRONTEND || defined ECPG_COMPILE
>> + #define PG_KEYWORD(a,b,c) {a,
Joshua Tolley wrote:
Way back in this thread[1] one of the arguments against allowing
some version of CREATE SYNONYM was that we couldn't create a synonym for
an object in a remote database. Will the SQL/MED work make this sort of
thing a possibility? I realize since it's not standard anyway, the
Tom Lane wrote:
> Heikki Linnakangas writes:
> > Perhaps this could be made less ugly by only having the ScanKeywords
> > array in the .c file, and #including that into other .c files in
> > src/backend/parser, ecpg and pg_dump.
>
> What I'd suggest is something similar to the design of the err
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Hmm, I had thought that pg_dump only wanted the header file, not the
keywords.o object file. I now see that I was wrong. I agree that your
proposed solution is a lot better. I'll see about it.
Here it is. The #ifdef parts seem a bit ugly, but I'
Heikki Linnakangas writes:
> Perhaps this could be made less ugly by only having the ScanKeywords
> array in the .c file, and #including that into other .c files in
> src/backend/parser, ecpg and pg_dump.
What I'd suggest is something similar to the design of the errcodes.h
header: create a hea
Alvaro Herrera wrote:
> Hmm, I had thought that pg_dump only wanted the header file, not the
> keywords.o object file. I now see that I was wrong. I agree that your
> proposed solution is a lot better. I'll see about it.
Here it is. The #ifdef parts seem a bit ugly, but I'm not sure how can
t
Greg Stark writes:
> On Wed, Mar 4, 2009 at 12:34 PM, Emmanuel Cecchet wrote:
>> This is problematic in situations where the output of the cast is involved
>> in some later join which returns incorrect results because of the extra
>> double quotes surrounding the table name. Is there a way to ove
Way back in this thread[1] one of the arguments against allowing
some version of CREATE SYNONYM was that we couldn't create a synonym for
an object in a remote database. Will the SQL/MED work make this sort of
thing a possibility? I realize since it's not standard anyway, there's
still a discussion
On Wed, Mar 04, 2009 at 10:28:42AM +0100, Magnus Hagander wrote:
> Joshua Tolley wrote:
> > On Wed, Mar 04, 2009 at 09:43:55AM +0100, Magnus Hagander wrote:
> >> So. I've updated the comment, and applied your patch. Thanks!
> >
> > What would it take to get it applied to a few earlier versions as
Fujii Masao wrote:
Currently, the startup process ignores SIGHUP.
The attached patch allows the startup process to re-read config file:
when SIGHUP arrives, the startup process also receives the signal
from postmaster and reload the settings in main redo apply loop.
Obviously, this is useful to
Martin Pihlak wrote:
Proposal attached. This adds two C functions:
List *GetForeignConnectionOptions(Oid serverid, Oid userid);
char *GetForeignConnectionString(Oid serverid, Oid userid);
One for obtaining all of the connection related options as a list, and
another for transforming these optio
On Wed, Mar 4, 2009 at 12:34 PM, Emmanuel Cecchet wrote:
> This is problematic in situations where the output of the cast is involved
> in some later join which returns incorrect results because of the extra
> double quotes surrounding the table name. Is there a way to override the
> default beha
Tom Lane wrote:
Emmanuel Cecchet writes:
It looks like the behavior of regclass is not consistent when table
names are quoted. The name is returned without the quotes if the name is
lower case with eventual trailing numbers, otherwise it is returned with
quotes.
It's intentional tha
Fujii Masao wrote:
Hi,
On Mon, Mar 2, 2009 at 4:59 PM, Heikki Linnakangas
wrote:
Fujii Masao wrote:
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
wrote:
I'm leaning towards option 3, but I wonder if anyone sees a better
solution.
4. Use the shared memory to tell the startup process a
On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut wrote:
> The question is how you want to implement this in a data type independent
> fashion. You can't assume that increasing the typmod is a noop for all data
> types.
Sure. See my previous answer on -hackers (I don't think this
discussion belo
On Wed, Mar 4, 2009 at 11:06 AM, Heikki Linnakangas
wrote:
> While this isn't a bug, it's a reasonable feature request. I've added this
> to the TODO page: http://wiki.postgresql.org/wiki/Todo#ALTER
>
> Patches are welcome.
I remember someone proposed a patch for that a long time ago:
http://arch
Joshua Tolley wrote:
> On Wed, Mar 04, 2009 at 09:43:55AM +0100, Magnus Hagander wrote:
>> So. I've updated the comment, and applied your patch. Thanks!
>
> What would it take to get it applied to a few earlier versions as well?
I guess you maintaining your own fork? ;-)
Simply put, earlier ver
Per discussion, here's a patch for pg_standby in REL8_3_STABLE. The
signal handling is changed so that SIGQUIT no longer triggers failover,
but immediately kills pg_standby, triggering FATAL death of the startup
process too. That's what you want with immediate shutdown.
SIGUSR1 is now accepted
On Wed, Mar 04, 2009 at 09:43:55AM +0100, Magnus Hagander wrote:
> So. I've updated the comment, and applied your patch. Thanks!
What would it take to get it applied to a few earlier versions as well?
- Josh
signature.asc
Description: Digital signature
Selena Deckelmann wrote:
> Tom Lane wrote:
>> Selena Deckelmann writes:
>>> From the comment in hba.c, it appears that the desired behavior is to
>>> have the system ignore the failure,
>> I'm not sure how you could possibly read that comment that way.
>
> Right. Sorry, poor choice of words. I me
Stefan Kaltenbrunner wrote:
> Stefan Kaltenbrunner wrote:
>> there will be planned maintenance tomorrow(4 March 2009) from 09:00 to
>> 10:00 CET for the following servers and corresponding services:
>>
>> barzan.postgresql.org - affecting:
>>
>> * xindi.postgresql.org (wiki.postgresql.org)
>> * r
Stefan Kaltenbrunner wrote:
there will be planned maintenance tomorrow(4 March 2009) from 09:00 to
10:00 CET for the following servers and corresponding services:
barzan.postgresql.org - affecting:
* xindi.postgresql.org (wiki.postgresql.org)
* rakhar.postgresql.org (planet.postgresql.org)
84 matches
Mail list logo
