On Wed, 9 Sep 2009, decibel wrote:
What might be more useful is a view that takes the guesswork out of using
pg_depend. Namely, convert (ref)classid into a catalog table name (or better
yet, what type of object it is), (ref)objid into an actual object name, and
(ref)objsubid into a real name.
On Mon, 2009-09-14 at 09:16 +0900, Itagaki Takahiro wrote:
> Another matter is that we use LOG level both cases of important
> activity logging and mere performance or query logging. Maybe
> we should have used another log level (PERFORMANCE?) for the
> latter case, and its priority is less than WA
2009/9/13 Hannu Krosing :
> On Sun, 2009-09-13 at 21:50 +0200, Pavel Stehule wrote:
>> Hello
>>
>> >
>> > ANY [TYPE] and SAME AS [TYPE OF] are syntactic sugar indeed, but they
>> > are much more SQL-like than needing to write "any" or anyelement(n) as
>> > argument type or return type
>> >
>>
>> I
2009/9/14 Tom Lane :
> Robert Haas writes:
>> So, I guess I'm sadly left feeling that we should probably reject this
>> patch. Anyone want to argue otherwise?
>
> +1. I'm really hoping to get something done about the plpgsql parsing
> situation before 8.5 is out, so this should be a dead end any
2009/9/13 decibel :
> On Sep 12, 2009, at 5:54 PM, Andrew Dunstan wrote:
>>
>> decibel wrote:
>>>
>>> Speaking of concatenation...
>>>
>>> Something I find sorely missing in plpgsql is the ability to put
>>> variables inside of a string, ie:
>>>
>>> DECLARE
>>> v_table text := ...
>>> v_sql text;
>
2009/9/14 Robert Haas :
> On Mon, Aug 24, 2009 at 3:19 PM, Pavel Stehule
> wrote:
>> I reworked patch to respect mentioned issues. - this patch still
>> implement mixed notation - I am thing so this notation is really
>> important. All others I respect. The behave is without change, fixed
>> some
Grzegorz Jaskiewicz writes:
> usual round of updates to the scan report.
> Today's report available at:
> http://zlew.org/postgresql_static_check/scan-build-2009-09-12-1/
Looks like the clang guys still have some work to do. The
null-dereference reports, in particular, seem to be willing to mak
Is it possible to convert from a Timestamp to time_t ? I see functions
mentioned in utils/timestamp.h for converting between TimestampTz and
time_t, but nothing for Timestamp.
What is the relationship between Timestamp and TimestampTz?
Scott Mohekey
Systems/Application Specialist – OnTrack – Telog
Magnus Hagander wrote:
> I have been working with josh tolley that changes some infrastructure
> around this, with one of the future goals to be able to implement just
> this kind of features. I need to merge some changes from josh, and
> will then try to post a wip patch as soon as possib
Peter Eisentraut wrote:
> Instead of translating the whole string, that is (picking a shorter
> example)
>
> N_("ALTER TEXT SEARCH PARSER name RENAME TO newname")
>
> we really only want to translate the placeholders, so it could look like
> this:
>
>appendPQExpBuffer(buf,
>
On Wed, Aug 19, 2009 at 9:49 AM, Tom Lane wrote:
> Jeff Janes writes:
> > If I read the code correctly, the only thing that is irrevocable is
> > that it writes into
> > rdt->next, and if it saved an old copy of rdt first, then it could
> > revoke the changes just
> > by doing rdt_old->next=NULL
test_fsync in tools/fsync pre-creates a 16MB file. If it is given a number
of iterations greater than 1024 (like one might use if trying to see what
happens when NVRAM gets filled, or on a journaling file system), than one of
the writes being timed will have to extend the size of the pre-created t
On Sun, 2009-09-13 at 21:20 -0400, Robert Haas wrote:
> I'm not sure there's any point in reviewing this patch in its present
> form. Barring objections (or a new version), I think we should mark
> this Returned with Feedback.
>
> ...Robert
Yeah, sounds reasonable. The new version probably won'
On Tue, Aug 11, 2009 at 12:09 AM, Pavel Stehule wrote:
> 2009/8/10 Tom Lane :
>> Robert Haas writes:
>>> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule
>>> wrote:
new patch add new contrib "transformations" with three modules
anotation, decode and json.
>>
>>> These are pretty good exa
Robert Haas writes:
> So, I guess I'm sadly left feeling that we should probably reject this
> patch. Anyone want to argue otherwise?
+1. I'm really hoping to get something done about the plpgsql parsing
situation before 8.5 is out, so this should be a dead end anyway.
On Thu, May 21, 2009 at 2:46 PM, Steve Prentice wrote:
> On May 21, 2009, at 10:52 AM, Tom Lane wrote:
>>
>> It's probably time to bite the bullet and redo the parser as has been
>> suggested in the past, ie fix things so that the main parser is used.
>> Ideally I'd like to switch the name resolut
On Mon, Aug 24, 2009 at 3:19 PM, Pavel Stehule wrote:
> I reworked patch to respect mentioned issues. - this patch still
> implement mixed notation - I am thing so this notation is really
> important. All others I respect. The behave is without change, fixed
> some bugs, enhanced regress tests.
T
On Thu, Sep 10, 2009 at 10:23 AM, Robert Haas wrote:
> On Thu, Sep 10, 2009 at 12:47 AM, Josh Williams wrote:
>> On Wed, 2009-09-09 at 11:30 -0500, decibel wrote:
>>> On Sep 9, 2009, at 8:05 AM, Peter Eisentraut wrote:
>>> > How is this better than just reading the information directly from
>>> >
Here is a patch to add a GUC parameter "syslog_line_prefix".
It adds prefixes to syslog and eventlog. We still have
"log_line_prefix", that will be used only for stderr logs.
We have a tip that log_line_prefix is not required for syslog
in the documentation, but we'd better to have independent set
Tom Lane wrote:
Josh Berkus writes:
It's not as if we don't have the ability to measure performance impact.
It's reasonable to make a requirement that new options to COPY
shouldn't slow it down noticeably if those options aren't used. And we
can test that, and even make such testing part
Tom Lane wrote:
> Itagaki Takahiro writes:
> > Can I reorder them to ERROR > WARNING > LOG ?
>
> No. That was an intentional decision. LOG is for stuff that we
> really want to get logged, in most cases. ERROR is very often not
> that interesting, and WARNING even more so.
I think the deci
On Sun, Sep 13, 2009 at 10:54:21PM +0300, Peter Eisentraut wrote:
> On fre, 2009-09-11 at 07:39 -0600, Joshua Tolley wrote:
> While your discovery is accurate and the change makes it consistent with
> other similar parameters, note that the previous wording is also
> completely correct. This while
Peter Eisentraut writes:
> Instead of translating the whole string, that is (picking a shorter
> example)
> N_("ALTER TEXT SEARCH PARSER name RENAME TO newname")
> we really only want to translate the placeholders, so it could look like
> this:
>appendPQExpBuffer(buf,
>
Peter Eisentraut wrote:
On sön, 2009-09-13 at 10:07 -0400, Andrew Dunstan wrote:
Add Unicode support in PL/Python
The buildfarm seems quite unhappy with this patch.
I am completely unable to reproduce the buildfarm failures, even with
different Python versions and the
On sön, 2009-09-13 at 10:07 -0400, Andrew Dunstan wrote:
> >>> Add Unicode support in PL/Python
> >> The buildfarm seems quite unhappy with this patch.
> > I am completely unable to reproduce the buildfarm failures, even with
> > different Python versions and the exact configure options that the
>
Thanks, for the your quick answer.
I'll study the way We can do this, to me is very important and very useful that
PostgreSQL has this feature.
Regards
"The hurry is enemy of the success: for that reason...Be patient"
Ing. Marcos L. Ortiz Valmaseda
Línea Soporte y Despliegue
Centro de Tecn
On Sep 12, 2009, at 5:54 PM, Andrew Dunstan wrote:
decibel wrote:
Speaking of concatenation...
Something I find sorely missing in plpgsql is the ability to put
variables inside of a string, ie:
DECLARE
v_table text := ...
v_sql text;
BEGIN
v_sql := "SELECT * FROM $v_table";
Of course, I'm
Josh Berkus writes:
> It's not as if we don't have the ability to measure performance impact.
> It's reasonable to make a requirement that new options to COPY
> shouldn't slow it down noticeably if those options aren't used. And we
> can test that, and even make such testing part of the patch re
Tom,
> [ shrug... ] Everybody in the world is going to want their own little
> problem to be handled in the fast path. And soon it won't be so fast
> anymore. I think it is perfectly reasonable to insist that the fast
> path is only for "clean" data import.
Why?
No, really.
It's not as if we
One of the main pains in translating PostgreSQL messages is translating
the SQL syntax synopses in psql. Things like:
msgid ""
"[ WITH [ RECURSIVE ] with_query [, ...] ]\n"
"SELECT [ ALL | DISTINCT [ ON ( expression [, ...] ) ] ]\n"
"* | expression [ [ AS ] output_name ] [, ...]\n"
"INTO
On Sun, 2009-09-13 at 21:50 +0200, Pavel Stehule wrote:
> Hello
>
> >
> > ANY [TYPE] and SAME AS [TYPE OF] are syntactic sugar indeed, but they
> > are much more SQL-like than needing to write "any" or anyelement(n) as
> > argument type or return type
> >
>
> I looked on possibilities in gram.y a
On fre, 2009-09-11 at 07:39 -0600, Joshua Tolley wrote:
> The current docs for autovacuum_max_workers suggest it should be modifiable
> with a reload, unless I'm reading in awfully silly ways this morning (which
> isn't entirely out of the question). Anyway, in the 8.3.7 and 8.5devel
> instances I'
Hello
>
> ANY [TYPE] and SAME AS [TYPE OF] are syntactic sugar indeed, but they
> are much more SQL-like than needing to write "any" or anyelement(n) as
> argument type or return type
>
I looked on possibilities in gram.y and I thing, type identifiers
"ANY TYPE" is possible without any problems
Marcos Luis Ortiz Valmaseda wrote:
> Regards to all the list.
> Where I can find the new feautures that will be implemented on the 8.5
> version?
See http://www.postgresql.org/developer/roadmap.
We're also doing preliminary developer-oriented alpha releases
throughout the 8.5 release cycle. You
Tom Lane wrote:
> Magnus Hagander writes:
>> On Fri, Sep 11, 2009 at 10:44, Heikki Linnakangas
>>> Here's a patch implementing that, and changing pgrename() to check for
>>> ERROR_SHARING_VIOLATION and ERROR_LOCK_VIOLATION like pgwin32_open()
>>> does, instead of ERROR_ACCESS_DENIED.
>
>> I have
Regards to all the list.
Where I can find the new feautures that will be implemented on the 8.5 version?
Is there included the posibility on a tablespace restrict to a user to use a
certain space inside it?
For example in Oracle you can do this:
CREATE TABLESPACE tb_space1
LOCATION '/mnt/Data'
O
Peter Eisentraut wrote:
On lör, 2009-09-12 at 21:34 -0400, Tom Lane wrote:
pet...@postgresql.org (Peter Eisentraut) writes:
Log Message:
---
Add Unicode support in PL/Python
The buildfarm seems quite unhappy with this patch.
I am completely unable to reproduce t
On lör, 2009-09-12 at 21:34 -0400, Tom Lane wrote:
> pet...@postgresql.org (Peter Eisentraut) writes:
> > Log Message:
> > ---
> > Add Unicode support in PL/Python
>
> The buildfarm seems quite unhappy with this patch.
I am completely unable to reproduce the buildfarm failures, even with
2009/9/9 Itagaki Takahiro :
> Alvaro Herrera wrote:
>> This INCLUDING STORAGE is supposed to copy reloptions?
>
> No. It copies only storage parameters of columns to control TOAST policy.
> It might be good to have some features to copy reloptions with convenient
> way, but it will be done in anot
2009/8/21 Brendan Jurd :
> 2009/8/21 Jeff Davis :
>> On Fri, 2009-08-21 at 12:23 +1000, Brendan Jurd wrote:
>>> The current behaviour seems to be predicated on the unique constraint
>>> being an integral part of the index itself. While this might be true
>>> from a system catalog point of view (pg
40 matches
Mail list logo
