Thread: #postgresql report

#postgresql report

From
Christopher Kings-Lynne
Date:
In line with my idea of keeping the hackers up to date with stuff in the 
IRC channel, here are the topics of the week:

* We have a request for granting on all tables every other day  (already 
in TODO)

* We have a request for how to change database encoding every other day 
(i suggest a warning in initdb if no encoding is specified - EVERY pgsql 
newbie fails to set it)

* People are always wanting to change column types - but that's now in CVS

Hmmm, can't think of anything else at the moment :)

Chris



Re: #postgresql report

From
Stephen Frost
Date:
* Christopher Kings-Lynne (chriskl@familyhealth.com.au) wrote:
> In line with my idea of keeping the hackers up to date with stuff in the
> IRC channel, here are the topics of the week:
>
> * We have a request for granting on all tables every other day  (already
> in TODO)

Hopefully with options to do it per-schema?  Additionally, some way of
defining default permissions for objects would be nice.  Both
per-database and per-schema, with the more specific per-schema
overriding, or being in addition to (as long as it's clearly documented
which).  Being in addition to might require logic for duplicate
checking, though I'd be mildly suprised if that logic didn't exist
already somewhere else for some reason.
Stephen

Re: #postgresql report

From
Jeff
Date:
Don't forget we get people nearly daily who are encountering problems 
because Debian stable ships with 7.2.  We've grown accustomed to giving 
7.4 (or at least 7.3) advice and often those things don't work on 7.2.  
(such as information_schema and set returning functions)

Hopefully this will go away if and when Debian releases a new stable 
release.

--
Jeff Trout <jeff@jefftrout.com>
http://www.jefftrout.com/
http://www.stuarthamm.net/



Re: #postgresql report

From
Stephen Frost
Date:
* Jeff (threshar@torgo.978.org) wrote:
> Don't forget we get people nearly daily who are encountering problems
> because Debian stable ships with 7.2.  We've grown accustomed to giving
> 7.4 (or at least 7.3) advice and often those things don't work on 7.2.
> (such as information_schema and set returning functions)
>
> Hopefully this will go away if and when Debian releases a new stable
> release.

Back-ports of up to 7.4.2 are available for the Debian stable release at
backports.org.
Stephen

Re: #postgresql report

From
Jeff
Date:
On Jun 15, 2004, at 11:25 AM, Stephen Frost wrote:
>
> Back-ports of up to 7.4.2 are available for the Debian stable release 
> at
> backports.org.
>

True enough, however it is still a common topic on the channel.
Not everyone is too keen on using backports either.

Just reporting what I was seeing in the channel.

--
Jeff Trout <jeff@jefftrout.com>
http://www.jefftrout.com/
http://www.stuarthamm.net/



Re: #postgresql report

From
Stephen Frost
Date:
* Jeff (threshar@torgo.978.org) wrote:
> True enough, however it is still a common topic on the channel.

It's good to let people who are asking know there's an option though.
I'm on the channel too, and do let people know when I see them asking
about it but I'm in 20-odd other channels. :)

> Not everyone is too keen on using backports either.

True enough, though in that case the Debian release management is likely
exactly what they're looking for.

> Just reporting what I was seeing in the channel.

Sure.
Stephen

Re: #postgresql report

From
Simon Riggs
Date:
On Tue, 2004-06-15 at 16:05, Jeff wrote:
> Don't forget we get people nearly daily who are encountering problems 
> because Debian stable ships with 7.2.  We've grown accustomed to giving 
> 7.4 (or at least 7.3) advice and often those things don't work on 7.2.  
> (such as information_schema and set returning functions)
> 

There is an argument there for splitting the support lists so that each
main release has its own channel. That way, advice will always be
appropriate to the release...

Also, we can add messages to the bottom appropriate to that release.

For example, tip #9 is set to be obsolete in 7.5, but its still much
needed advice for anybody below that level.

That would also remind people to upgrade??

Just and idea...

Best regards, Simon Riggs



Re: #postgresql report

From
Peter Eisentraut
Date:
Christopher Kings-Lynne wrote:
> * We have a request for how to change database encoding every other
> day

This is pretty much impossible.  It's analogous to changing, say, the 
endianness of all integers.  You would need to rewrite the entire 
database.  But pg_dump & restore already does that.

> (i suggest a warning in initdb if no encoding is specified -
> EVERY pgsql newbie fails to set it)

Hm...



Re: #postgresql report

From
"Marc G. Fournier"
Date:
On Tue, 15 Jun 2004, Peter Eisentraut wrote:

> Christopher Kings-Lynne wrote:
>> * We have a request for how to change database encoding every other
>> day
>
> This is pretty much impossible.  It's analogous to changing, say, the
> endianness of all integers.  You would need to rewrite the entire
> database.  But pg_dump & restore already does that.

Just a thought here ... but, how about some sort of CREATE DATABASE 
extension that would transparently do the dump/restore, with the restore 
based on the new encoding?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


Re: #postgresql report

From
Josh Berkus
Date:
KL,

> In line with my idea of keeping the hackers up to date with stuff in the
> IRC channel, here are the topics of the week:

You want me & David Fetter should keep a suppliment to this?   Since we're on 
IRC while you're asleep, usually?

Admittedly, most of the discussion for the last 2 days has boiled down to:
a) troubleshooting newbie problems, and
b) troubleshooting crashes, and 
c) Slony

... none of which is worth reporting here.    Except to say that most of the 
Slony team is on IRC most of the time ...

-- 
Josh Berkus
Aglio Database Solutions
San Francisco


Re: #postgresql report

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> Christopher Kings-Lynne wrote:
>> * We have a request for how to change database encoding every other
>> day

> This is pretty much impossible.  It's analogous to changing, say, the 
> endianness of all integers.  You would need to rewrite the entire 
> database.  But pg_dump & restore already does that.

I wonder though, do the requestors actually know what they're asking for?
Are they really asking for encoding changes, or are they asking for
locale changes?

>> (i suggest a warning in initdb if no encoding is specified -
>> EVERY pgsql newbie fails to set it)

> Hm...

initdb already tells you pretty clearly what locale it's picking.
I think people don't read the message and/or don't understand the
implications.

IMHO the *real* issues here boil down to two things:

1. You can't change locale after initdb.  Even a per-database locale
setting would be better than that (though of course the SQL spec sets
the bar much higher, namely per-column locales).

2. You can shoot yourself in the foot by selecting a database encoding
that's not compatible with the (fixed) locale.

AFAICS there is not very much we can do about either of these things
without creating our own locale support layer so we can stop depending
on the standard C library's inflexible and taciturn API.

Peter has mentioned that he is working on that but that it might be
a year or so before it's ready.  Is that still a reasonable guess?
        regards, tom lane


Re: #postgresql report

From
"Dann Corbit"
Date:
> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
> Sent: Tuesday, June 15, 2004 12:04 PM
> To: Peter Eisentraut
> Cc: Christopher Kings-Lynne; Hackers
> Subject: Re: [HACKERS] #postgresql report
>
>
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Christopher Kings-Lynne wrote:
> >> * We have a request for how to change database encoding
> every other
> >> day
>
> > This is pretty much impossible.  It's analogous to
> changing, say, the
> > endianness of all integers.  You would need to rewrite the entire
> > database.  But pg_dump & restore already does that.
>
> I wonder though, do the requestors actually know what they're
> asking for? Are they really asking for encoding changes, or
> are they asking for locale changes?
>
> >> (i suggest a warning in initdb if no encoding is specified - EVERY
> >> pgsql newbie fails to set it)
>
> > Hm...
>
> initdb already tells you pretty clearly what locale it's
> picking. I think people don't read the message and/or don't
> understand the implications.
>
> IMHO the *real* issues here boil down to two things:
>
> 1. You can't change locale after initdb.  Even a per-database
> locale setting would be better than that (though of course
> the SQL spec sets the bar much higher, namely per-column locales).

How about (at least) a per object locale setting as a goal?

Have a system table that tracks it.  The system table could be flexible
enough to describe objects of any sort (tables, stored procedures...)
and perhaps be extended to columns eventually.

I can't think of any time I wanted more than one locale in a single
table (and think of how confusing it could become to have 19 different
locales in a single table, expecially if some of the users were not
aware of them).  But sometimes, a different locale for different tables
can be very useful [e.g. processing orders from different countries].
Actually, I am used to having different codepages, but I imagine that
maps to different locales directly.  It seems that the inheritance of
PostgreSQL might be nice to implement this feature in a natural way.

E.g.
NorwegianAddress inherits from Address, but sets the codepage for
Norway.

And things like FrenchAddress would know about 'Rue' instead of
'Street', etc.

> 2. You can shoot yourself in the foot by selecting a database
> encoding that's not compatible with the (fixed) locale.
>
> AFAICS there is not very much we can do about either of these
> things without creating our own locale support layer so we
> can stop depending on the standard C library's inflexible and
> taciturn API.
>
> Peter has mentioned that he is working on that but that it
> might be a year or so before it's ready.  Is that still a
> reasonable guess?
>
>             regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to
> majordomo@postgresql.org)
>


Re: #postgresql report

From
Dennis Bjorklund
Date:
On Tue, 15 Jun 2004, Tom Lane wrote:

> I wonder though, do the requestors actually know what they're asking for?
> Are they really asking for encoding changes, or are they asking for
> locale changes?

Most people don't know exactly what they want.

A lot of people use SQL_ASCII databases and don't know exactly what they
have put in there. Often they need help to know what they use today and
then they need help to dump and restore. In most cases people are
converting from something to unicode.

-- 
/Dennis Björklund



Re: #postgresql report

From
Christopher Kings-Lynne
Date:
> In line with my idea of keeping the hackers up to date with stuff in the 
> IRC channel, here are the topics of the week:

Ah yes, I forgot to add:

* pg_dumpall -Fc option comes up occasionally

Chris