Andrus wrote:
Then redesign this as a many to many relation. ...
This means adding separate row for each department into permission table.
Not really.
You can of course store an Array of department IDs in that same table.
That would probably cause the minimum impact on your queries too.
---
Jim C. Nasby wrote:
On Thu, Jul 14, 2005 at 11:29:23PM +0200, Martijn van Oosterhout wrote:
On Thu, Jul 14, 2005 at 11:30:36AM -0500, Jim C. Nasby wrote:
On Wed, Jul 13, 2005 at 07:52:04PM -0400, Bruce Momjian wrote:
This is a good point. We have always stored data on disk that exactly
match
I was faced with a similar issue. One suggestion I got from the
Internet was to create a shadow column that contains the values used in the
Index, with a dummy entry (in my case, the string ) for those
records in which the primary column is NULL. It works well for my
app.
I have this structure:
CREATE TABLE invoicelineitemtypes (
invoicelineitemtypeid varchar(36) PRIMARY KEY,
otherstuff varchar(36)
);
CREATE TABLE invoicelineiteminventorytypes (
moresetuff varchar(36)
)
INHERITS (invoicelineitemtypes);
CREATE TABLE invoicelines (
invoicelineitemt
Christian Traber wrote:
> Now I know a I cannot use every lc_ctype with every encoding,
> but where can I find a list of valid encoding/locale combinations?
Try something like the following:
for x in $(locale -a); do echo -n "$x: "; LC_ALL=$x locale charmap; done
Unfortunately, the name of the e
16. července 2005, 16:46:59, napsal jste:
> In other words: what you probably meant here is
> FROM (c_custom_fields AS fieldx CROSS JOIN
> j_product_groups_fields AS join_table)
> LEFT JOIN c_custom_fields_options AS optionx ON optionx.field_id =
> fieldx.field_id
Thank you, your query runs but
Thomas Chille <[EMAIL PROTECTED]> writes:
> I dumped from a 7.3.4 server on debian with kernel 2.6 using this command:
> pg_dump -F c -Z 9 -f backoffice.dmp.c backoffice
> I tried to restore on a similiar system using:
> pg_restore -vd backoffice backoffice.dmp.c
> and stepped into an error:
> ERR
Christian Traber <[EMAIL PROTECTED]> writes:
> Now I know a I cannot use every lc_ctype with every encoding,
> but where can I find a list of valid encoding/locale combinations?
If there were a standardized way of finding that out, we'd long since
have made Postgres take advantage of it to prevent
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Sat, 16 Jul 2005, [ISO-8859-2] Jiøí Nìmec wrote:
>> There's a problem with PostgreSQL 8.0.3 SELECT. All tables exist, all
>> columns exist, I have no idea where's the problem :/ PostgreSQL
>> reports this error: ERROR: relation "fieldx" does not exist
i forgot to attach the error messages. but now!
t
On 7/16/05, Thomas Chille <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I dumped from a 7.3.4 server on debian with kernel 2.6 using this command:
>
> pg_dump -F c -Z 9 -f backoffice.dmp.c backoffice
>
>
> I tried to restore on a similiar system using
Hi!
I dumped from a 7.3.4 server on debian with kernel 2.6 using this command:
pg_dump -F c -Z 9 -f backoffice.dmp.c backoffice
I tried to restore on a similiar system using:
pg_restore -vd backoffice backoffice.dmp.c
and stepped into an error:
ERROR: copy: line 270892, Missing data for c
I'm using postgres8 with encoding 'UNICODE'.
I have some problems with unsupported mutlibyte... e.g. with upper()
Now I know a I cannot use every lc_ctype with every encoding,
but where can I find a list of valid encoding/locale combinations?
regards
Christian
---(end of
Thanks, that looks useful. I'll investigate once I've got the servers upgraded
and replication running.
Bruno Wolff III wrote:
>
> On Wed, Jul 13, 2005 at 18:15:12 +,
> [EMAIL PROTECTED] wrote:
> > Many thanks Tom. Inconvenient from the point of view of the application
> > but still useful
Am Samstag, den 16.07.2005, 09:19 +0200 schrieb Jiří Němec:
> Hello,
>
> There's a problem with PostgreSQL 8.0.3 SELECT. All tables exist, all
> columns exist, I have no idea where's the problem :/ PostgreSQL
> reports this error: ERROR: relation "fieldx" does not exist...
>
> SELECT fieldx.fiel
On Sat, 16 Jul 2005, [ISO-8859-2] Ji?? N?mec wrote:
> There's a problem with PostgreSQL 8.0.3 SELECT. All tables exist, all
> columns exist, I have no idea where's the problem :/ PostgreSQL
> reports this error: ERROR: relation "fieldx" does not exist...
>
> SELECT fieldx.field_id, COUNT(optionx.
Hello,
There's a problem with PostgreSQL 8.0.3 SELECT. All tables exist, all
columns exist, I have no idea where's the problem :/ PostgreSQL
reports this error: ERROR: relation "fieldx" does not exist...
SELECT fieldx.field_id, COUNT(optionx.option_id) AS field_options
FROM c_custom_fields AS fi
My main disk for Postgresql crashed but I still have the database as it was
stored on a tablespace on another disk. Now the problem is how to recover from
this situation.
What I have tried is to restore the database from a backup from a few houres
before the crash and then replacing the direct
17 matches
Mail list logo
