Re: [HACKERS] [COMMITTERS] pgsql-server: Clean up generation of

2004-06-13 Thread Tom Lane
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > I'm trying to avoid doing it in C as it seems like it would be a pita. I think it would be simpler in C than this mess in SQL is ;-). You would not of course implement it in any way that would look like the SQL query ... but there are existing

Re: [HACKERS] [COMMITTERS] pgsql-server: Clean up generation of

2004-06-13 Thread Christopher Kings-Lynne
> The right way to do this at the C level would be to use the same > infrastructure as nextval() does to accept arguments like 'foo' and > '"Foo"."Bar"'. There's no reason to restrict the two-argument form > to the current search_path. Is it possible to do that in SQL? eg. is there anything you

Re: [HACKERS] [COMMITTERS] pgsql-server: Clean up generation of default

2004-06-12 Thread Tom Lane
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > OK, attached is a file with the original function, and an overloaded one > that just takes table and column. It searches your current search_path > to find the first matching table. The right way to do this at the C level would be to use the

Re: [HACKERS] [COMMITTERS] pgsql-server: Clean up generation of default

2004-06-12 Thread Christopher Kings-Lynne
I'd be inclined to make it only take 2 args, table, col where table can be namespace qualified. This allows people who arn't namespace aware to just do SELECT pg_get_serial_sequence('mytable','mycol') and have it return the correct item following searchpath.. I would think this would then bec

Re: [HACKERS] [COMMITTERS] pgsql-server: Clean up generation of default

2004-06-11 Thread Darcy Buskermolen
On June 11, 2004 05:51 am, Christopher Kings-Lynne wrote: > >>> 3. Or even create a pg_get_sequence() function: > >>> SELECT SETVAL(pg_get_sequence(schema.table, col), 17); > >> > >> Actually, this is the best solution :) > > OK, attached is a pg_get_serial_sequence(schema, table, column) function

Re: [HACKERS] [COMMITTERS] pgsql-server: Clean up generation of default

2004-06-11 Thread Christopher Kings-Lynne
3. Or even create a pg_get_sequence() function: SELECT SETVAL(pg_get_sequence(schema.table, col), 17); Actually, this is the best solution :) OK, attached is a pg_get_serial_sequence(schema, table, column) function . I have tested it with crazy names and it seems to be good. It works like this

Re: [HACKERS] [COMMITTERS] pgsql-server: Clean up generation of default

2004-06-10 Thread Michael Glaesemann
On Jun 11, 2004, at 1:02 PM, Christopher Kings-Lynne wrote: 3. Or even create a pg_get_sequence() function: SELECT SETVAL(pg_get_sequence(schema.table, col), 17); Actually, this is the best solution :) John Hansen and I worked this up. It works, though it's not schema-aware, afaict. create or rep

Re: [HACKERS] [COMMITTERS] pgsql-server: Clean up generation of default

2004-06-10 Thread Christopher Kings-Lynne
3. Or even create a pg_get_sequence() function: SELECT SETVAL(pg_get_sequence(schema.table, col), 17); Actually, this is the best solution :) Chris ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subs

Re: [HACKERS] [COMMITTERS] pgsql-server: Clean up generation of default names

2004-06-10 Thread Christopher Kings-Lynne
Yeah, I know ... we ought to find some way around that, but I dunno what yet ... My idea, which I tried hacking, but gave up was to do the following: 1. Extend this command: ALTER SEQUENCE seqname RESTART WITH 17; to allow: ALTER SEQUENCE ON table(col) RESTART WITH 17... or ALTER SEQUENCE ON table.

Re: [HACKERS] [COMMITTERS] pgsql-server: Clean up generation of default names

2004-06-10 Thread Tom Lane
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > Then if the name given to the id sequence is now different, these dumps > will not restore. (In this case it will be the same, I'm just > illustrating the general problem of hard-coding those sequence names in > the dump - I've never liked i

Re: [HACKERS] [COMMITTERS] pgsql-server: Clean up generation of default names

2004-06-10 Thread Christopher Kings-Lynne
(moved to -hackers) If you use sufficiently long table/field names then different tables could truncate to the same generated names, and in that case there's some risk of concurrently choosing the same "unique" name. But I don't recall anyone having complained of that since we started using this t