Re: psql - user defined SQL variables
От | Jean-Luc Lachance |
---|---|
Тема | Re: psql - user defined SQL variables |
Дата | |
Msg-id | 4123C005.9070000@sympatico.ca обсуждение исходный текст |
Ответ на | Re: psql - user defined SQL variables (Grainne Reilly <greilly1@comcast.net>) |
Ответы |
Re: psql - user defined SQL variables
|
Список | pgsql-general |
What do you mean varables do not exists? Ever heard of SELECT INTO? Grainne Reilly wrote: > Thanks for the response - pity PostgreSQL doesn't have this. These are a > bunch of quick and dirty data population scripts which I was hoping to > avoid rewriting to use temporary tables, subselects etc. > It is a useful feature for these kind of scripts (Sybase has it and it > has always had subselects) - and in Oracle I can use an anonymous PL/SQL > block to declare and use variables directly in sqlplus. > Are there any plans for PostgreSQL to support anonymous PL/pgSQL blocks > directly in psql - now that would be very nice! > Thanks again. > Grainne. > > > At 01:48 AM 8/18/2004, David Fetter wrote: > >> On Wed, Aug 18, 2004 at 12:22:27AM -0400, Grainne Reilly wrote: >> > I am new to PostgreSQL and am porting some scripts written for MySQL >> > over to psql. >> >> The least work you'll do here is to refactor your app entirely. >> >> PostgreSQL will just plain handle about 3/4 of what you used to have >> to deal with up in middleware land. It also supports all kinds of >> wizardry that will astound you as you run across it. :) >> >> > There is one MySQL feature which I cannot find in psql - user >> > defined SQL variables. In MySQL I can use these to hold the result >> > (numeric, string or null) of a select: e.g. select @count = >> > count(*) from mytable; >> >> This is a MySQLism to work around their lack of subselects. But if >> that turns out not to be enough, you have a broad choice of procedural >> languages, from the ADA-like PL/PgSQL to PL/Perl, PL/Python and (soon) >> PL/PHP. >> >> > Thanks in advance for any suggestions, >> >> See about redoing your app. It will be less work than trying to graft >> the MySQL design onto PostgreSQL, which is about like trying to hook >> an ox cart to a jet engine :) >> >> Cheers, >> D >> -- >> David Fetter david@fetter.org http://fetter.org/ >> phone: +1 510 893 6100 mobile: +1 415 235 3778 >> >> Remember to vote! >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 9: the planner will ignore your desire to choose an index scan if >> your >> joining column's datatypes do not match > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org >
В списке pgsql-general по дате отправления: